[Standards] Dynamic Forms

Peter Waher Peter.Waher at clayster.com
Fri Dec 20 20:34:26 UTC 2013


Hello Lance



Thanks for the valuable input, and sorry for the delayed response. I'll respond to your concerns one at a time:



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>



    <iq type="result">

      <formPostBackResponse result='NotFound'>...</formPostBackResponse>

    </iq>



    <iq type="result">

      <formPostBackResponse result='OtherError'>

        <error>...</error>

      </formPostBackResponse>

    </iq>



    <iq type="result">

      <cancelResponse result='OK' />

    </iq>



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'>

        ...

      </formPostBack>

    </iq>



    <iq type="error">

      <error type="cancel">

        <item-not-found />

      </error>

    </iq>



    <iq type="error">

      <error type="cancel">

        <relevant-existing-stanza-error-condition />

        <text>...</text>

        <some-to-be-defined-xdata-dynamic-error-condition />

      </error>

    </iq>



    <iq type="result" />



This has been updated as you suggested in the revised version (attached).



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="..." />

      ...

    </x>



along with:



    <iq type="set">

      <formPostBack sid="...">

        ...

      </formPostBack>

    </iq>



    <message>

      <formUpdated sid="...">

        ...

      </formUpdated>

    </message>



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="..." />

   </x>



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



The problem here is that the xdd session is just an example. Hidden fields are normally used for session or state information. It might not be a session, it might be a sequence of variables identifying the form (node Id, dialog id, user id, etc.). The idea was for it to be implementation specific.



However, another idea might be to update XEP-0004 to allow hidden fields in cancel operations. That would also solve the problem, and remove the need to publish a new cancel operation for this XEP.



I would also like to request the following, while discussing XEP-0004: I would like to add wildcards (<xs:any.../>) in the schema in appropriate places so that Data form Validation, Layout and Dynamic Forms (etc.) can be used using default schemas without breaking validation. As it is now, separate (custom made) schemas have to be used if using these XEPs together with EXI for instance. (EXI in schema-informed mode can only stream valid XML according to the schemas used.)



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



Note added regarding this at the end of §3.6.





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.



Ok. As he has not posted any comments I hope any such concerns will not block its acceptance as experimental at this stage.





// 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)

    updated

    postBack

    readOnly

    notSame

    error



I've updated the elements according to your suggestions. New version is attached.



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



Thanks. I hope it will pass into experimental in its current state.



Best regards,

Peter Waher


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20131220/34d626f3/attachment.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20131220/34d626f3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dynamic-forms.xml
Type: application/xml
Size: 51509 bytes
Desc: dynamic-forms.xml
URL: <http://mail.jabber.org/pipermail/standards/attachments/20131220/34d626f3/attachment.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dynamic-forms.xsd
Type: text/xml
Size: 1715 bytes
Desc: dynamic-forms.xsd
URL: <http://mail.jabber.org/pipermail/standards/attachments/20131220/34d626f3/attachment-0001.xml>


More information about the Standards mailing list