[Standards] Data Forms Discovery

[JD Conley]

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/b92c9792/attachment.html