[Standards] Data Forms Discovery

[Nathan Fritz]

3. "The <x/> element qualified by the 'jabber:x:data' namespace SHOULD be
included as a first-level child of an XML stanza; the stanza MAY be of any
kind (<iq/>, <message/>, or <presence/>), although it is RECOMMENDED to use
<iq/> or <message/> (see also the restrictions enumerated below)."

10. "The <x/> element MAY be included in <message/> and <presence/>
elements."

I assume this to mean that we can send forms in messages, and why not?  It's
a great feature for bots.  I see no need for it to be contained in an
additional protocol, because it doesn't require any additional context.  As
far as finding it implemented in this way, I know of a client that it
already is (Psi 0.11).

Additionally, why should I, as an implementer, care what most clients will
do?  I simply want the best experience for the clients that /can/ support
it.

On 4/16/07, JD Conley <jd.conley at coversant.net> wrote:
>
>  Typically x:data is used in the context of another protocol, like Ad-Hoc
> Commands (0050), MUC (0045), PubSub (0060), etc. It is up to the concrete
> protocol to determine when the x:data is relevant. If you have a custom bot
> service you could use Ad-Hoc commands or implement your own namespace that
> by definition assumes support for x:data. I think what you'd be looking for
> in client support would be if they support your specific protocol that uses
> x:data. You can glean this from Entity Capabilities (0115) or directly
> through discovery info like you mention. You'll be hard pressed to find a
> protocol that most existing clients will implement that will present a form
> to the user.
>
>
>
> -JD
>
>
>
> *From:* standards-bounces at xmpp.org [mailto:standards-bounces at xmpp.org] *On
> Behalf Of *Nathan Fritz
> *Sent:* Monday, April 16, 2007 10:27 AM
> *To:* standards at xmpp.org
> *Subject:* [Standards] Data Forms Discovery
>
>
>
> While implementing XEP-0004, I ran through a scenario in my head.  Let's
> say a bot wants to present a survey or voting form to a user.  The preferred
> presentation would be literally a form, but let's say the bot can present
> and interpret standard <message><body/></message> stanzas as well.  The bot
> has, with the current XEP, no way of reliably knowing whether the client
> supports jabber:x:data stanzas.  Additionally, since jabber:x:data stanzas
> are acceptable within message, presence, and iq stanzas (although iq stanzas
> generally the context of another feature and namespace), the bot would have
> to prompt the user manually for a preference of form data or raw data, to
> which the user may not know how to respond.
>
> Ideally, the the bot would be able to do a Service Discovery #info query
> to the end user and look for the results of jabber:x:data,
> jabber:message:x:data, jabber:presence:x:data, or something similar in the
> resulting features.  Perhaps simply jabber:x:data would be enough, although
> it would have to mean that Data Forms are acceptable within the
> jabber:client namespace, and would not be inferred from support of another
> protocol like XEP-0146.
>
> Any thoughts?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/standards/attachments/20070416/e8d47a17/attachment.html