XEP-0004 co-author here...
On 7/17/22 9:05 AM, Sam Whited wrote:
Several people [1, 2] have recently asked about how to use multi-item
data forms. XEP-0004 when introducing multi-item forms says:
Therefore, a data form of type "result" MAY contain two child elements
not described in the basic syntax above
Then proceeds to give examples using the reported/items. However, the
text makes it sound like these XML elements might be in addition to
existing elements such as title/introduction and various fields
Maybe. The text in effect says "here are some additional elements not
mentioned so far in the spec", not "these new elements are included in
addition to other elements within the XML".
(though
there are no examples where a form contains reported/items and any other
form element).
The lack of examples is indeed not good.
This would lead to a lot of edge cases (what if you have
a field in between multiple items?) that also aren't described by the
XEP, which makes me wonder what the original intent is and how we should
interpret it going forward.
If I recall correctly, the use case we had in mind was search: send a
keyword to the form processor and get back a set of results. The
<reported/> element tells you what you searched for, and each <item/>
element defines one of the hits. Of course, later on (in XEP-0055) we
created a special namespace for search, as well as a method (XEP-0059)
for managing large results sets.
What use cases do folks have in mind nowadays for multi-item data forms
of type 'result'?
Looking over a few existing libraries, they appear to interpret this
differently.
Do these libraries allow multiple items in forms of type 'cancel',
'form', and 'submit', or only 'result'?
For example:
- aioxmpp and nbxmpp do not allow mixed fields/items, but do allow multi-
item forms with instructions, although this appears to be incorrect no
matter how you interpret the spec, but makes a sort of logical sense
- smack allows mixing fields and items but if parsing a form with them
it loses ordering between fields and items while maintaining ordering
between fields and items individually, eg. in the form "field1, item1,
field2, item2" you could ask Smack for fields and it would give you
"field1, field2" or items and it would give you "item1, item2"
Since the spec is not clear and users of these libraries could easily
write forms that would be compatible with some clients and incompatible
with others (without the user realizing they've done this), I think we
should find a way to clear up the inconsistency, possibly with a new
informational XEP. A few options have been discussed:
1. Disallow mixing fields/items (possibly allowing instructions on both)
2. Allow mixing fields/items and treat them as separate ordered entities
that should be displayed separately
3. Treat individual items as fields to be displayed in a column and
allow them to be ordered together (ie. item is effectively just a
field with multiple values that are themselves fields and it happens
to have a slightly different wire representation)
I'd love to hear what other libraries do or any pros/cons of the above.
In [2] it was suggested that the jmp.chat folks would like to display a
form containing your account balance, followed by a table of recent
transactions. This could be allowed by option 1 only if we also specify
that multiple forms should be displayed one after the other; I am unsure
if this conflicts with the use of multiple-forms in existing specs.
Option 2 and 3 it would just work.
Your thoughts would be appreciated.
Although I'm not sure if (1) is ideal (it depends on what use cases
people have), but I think it is most consistent with the original intent
for forms of type 'result' that include a <reported/> element.
HTH,
Peter
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
