Re: [Standards] XEP-0235: data forms?
On Thu, 03 Apr 2008 10:47:48 -0600 Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > Pedro Melo wrote: > > > 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. > > Sure, that's because humans are a lot more flexible than machines. :) > Fortunately. :) > /psa > -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] XEP-0235: data forms?
On Mon, Mar 31, 2008 at 12:38 PM, Pedro Melo <[EMAIL PROTECTED]> wrote: > > 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? Yep, it was just badly written. Rendering is the only purpose of forms I see, especially when you don't know in advance the fields or, even if statically defined, when they are complex and you need some layout. bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
Re: [Standards] XEP-0235: data forms?
Pedro Melo wrote: > 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. Sure, that's because humans are a lot more flexible than machines. :) /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0235: data forms?
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!
Re: [Standards] XEP-0235: data forms?
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). P -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0235: data forms?
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. > > > In the other cases as best practice I wouldn't abuse > > on them, in order not to be too much verbose (though we may find a > > way to "binarize" them ;)) > > One binary form will rule them all... > > Best regards, -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] XEP-0235: data forms?
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? In the other cases as best practice I wouldn't abuse on them, in order not to be too much verbose (though we may find a way to "binarize" them ;)) One binary form will rule them all... Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] XEP-0235: data forms?
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). In the other cases as best practice I wouldn't abuse > on them, in order not to be too much verbose (though we may find a way > to "binarize" them ;)) Right, that's when we use data forms. But an authorization token is a small, atomic data unit, so I think it's best to use "nice semantic XML" in this case. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0235: data forms?
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). In the other cases as best practice I wouldn't abuse on them, in order not to be too much verbose (though we may find a way to "binarize" them ;)) -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
Re: [Standards] XEP-0235: data forms?
Hi, On Mar 29, 2008, at 2:52 AM, Peter Saint-Andre wrote: Pedro Melo poked me via IM about XEP-0235 (Authorization Tokens), specifically to ask me why the protocol uses data forms. I didn't have a good answer. Since he challenged me about it, I've realized that using data forms here doesn't especially make sense, so I may change that in the next version of the spec. 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. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
[Standards] XEP-0235: data forms?
Pedro Melo poked me via IM about XEP-0235 (Authorization Tokens), specifically to ask me why the protocol uses data forms. I didn't have a good answer. Since he challenged me about it, I've realized that using data forms here doesn't especially make sense, so I may change that in the next version of the spec. Just so you know. :) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
