Hi,
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 <[EMAIL PROTECTED]> wrote:
On Mar 30, 2008, at 6:18 PM, Fabio Forno wrote:
On Sat, Mar 29, 2008 at 8:59 PM, Pedro Melo
<[EMAIL PROTECTED]> 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-
to-human).
Forms are great for humans, not so great for software-to-software.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [EMAIL PROTECTED]
Use XMPP!
