[Standards] Dynamic Forms

Lance Stout lancestout at gmail.com
Wed Dec 11 22:42:40 UTC 2013

I remembered that I promised to give this a more thorough review on list
after voting for moving this to Experimental, since the Council had some
concerns that will need to be addressed before this would be approved to
advance to Draft (See http://logs.xmpp.org/council/131127/)

1) The primary concern is with how results are served. Currently, results
always come back in an IQ of type 'result' and look like (details omitted
for brevity):

    <iq type="result">
      <formPostBackResponse result='OK'>…</formPostBackResponse>

    <iq type="result">
      <formPostBackResponse result='NotFound'>…</formPostBackResponse>

    <iq type="result">
      <formPostBackResponse result='OtherError'>

    <iq type="result">
      <cancelResponse result='OK' />

The problem is that this bypasses and duplicates the existing result/error
functionality provided by IQs. At the same time, it also is introducing
*Response elements for results, which isn't the pattern used by current
XEPs. (My understanding is that this new pattern has been introduced in
the recent IoT experimental XEPs in order to squeeze some extra bytes out
of EXI compression.)

The above examples could then look like:

    <iq type="result">
      <formPostBack xmlns='urn:xmpp:xdata:dynamic'>

    <iq type="error">
      <error type="cancel">
        <item-not-found />

    <iq type="error">
      <error type="cancel">
        <relevant-existing-stanza-error-condition />
        <some-to-be-defined-xdata-dynamic-error-condition />

    <iq type="result" />

2) The secondary issue is the XDD session. Using sessionVariable feels very
awkward and requires the introduction of a new form cancelation mechanism.
One possible alternative would be something like:

    <x xmlns="jabber:x:data" type="form">
      <session xmlns="urn:xmpp:xdata:dynamic" id="..." />

along with:

    <iq type="set">
      <formPostBack sid="...">

      <formUpdated sid="...">

There would then be no need for the new <cancel /> action, and canceling a
form would be done via the existing form canceling behaviour:

   <x xmlns="jabber:x:data" type="cancel">
     <session xmlns="urn:xmpp:xdata:dynamic" id="..." />

(It would have been nice if Data Forms had included an id for forms, but alas.)

It may also be useful to mention that the relevant dynamic form sessions
should also be ended when canceling a wrapping adhoc command session.

3) There was concern from Tobias regarding how dynamic form processing
interferes with UI, as noted in section 3.2. He will need to respond with
his concerns; it seems OK enough to me.

// Switching to non-Draft blocking review

Regarding the element names, I think we could drop 'form' from the names,
since the namespace already states that we're dealing with xdata forms. I'd
go with a set of elements like:

    submit (as replacement for formPostBack, since postBack already exists with different semantics)

All of that said, I think this XEP has a lot of good potential, and I have
some use cases in mind that could make good use of it.

— Lance

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.jabber.org/pipermail/standards/attachments/20131211/93e04eb9/attachment.sig>

More information about the Standards mailing list