[Standards] XEP-0235: data forms?

Pedro Melo melo at simplicidade.org
Thu Apr 3 06:43:23 UTC 2008


On Apr 2, 2008, at 10:38 PM, Peter Saint-Andre wrote:
> pavlix wrote:
>> On Mon, 31 Mar 2008 11:38:05 +0100
>> Pedro Melo <melo at simplicidade.org> wrote:
>>> On Mar 30, 2008, at 6:18 PM, Fabio Forno wrote:
>>>> On Sat, Mar 29, 2008 at 8:59 PM, Pedro Melo
>>>> <melo at simplicidade.org> wrote:
>>>>>  I have nothing very strong against Data Forms. My point was
>>>>> that, for
>>>>>  clients that use XPath to parse the known parts of the stanza  
>>>>> (and
>>>>>  transparently ignore anything that the client does not support),
>>>>> data
>>>>>  forms are a bit messy :) and a nice semantic XML is much  
>>>>> easier to
>>>>>  parse.
>>>> In fact I'd say that Data Forms are good when you don't know in
>>>> advance all the possible fields, or when you have complex input
>>>> schemes that must be rendered in clients (e.g. muc or pubsub
>>>> configuration).
>>> I think that only the second case holds, when you need to present it
>>> to a human.
>>> If you don't know in advance the fields, your software will not know
>>> what to do with them either, right?
>> Exactly.
> Sure, but the service will send you only the fields it understands,  
> and
> your client will just present a data form and you'll fill in what you
> know (the client doesn't need to understand all the form fields, just
> like your browser doesn't need to understand the fields in an HTML  
> form).

But I'm not opposed to the forms when they will be used to interact  
with some-sort-of-human. I think that when a protocol will be used  
between software only, data-forms are not the best way to do it. As I  
said above, only the second case is a valid use for forms (software- 

Forms are great for humans, not so great for software-to-software.

Best regards,
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo at simplicidade.org

More information about the Standards mailing list