[Standards] What to do about multi-item data forms?
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 (though there are no examples where a form contains reported/items and any other form element). 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. Looking over a few existing libraries, they appear to interpret this differently. 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. —Sam [1]: https://logs.xmpp.org/xsf/2022-06-07?p=h#2022-06-07-50bc9a07d99ec16a [2]: https://logs.xmpp.org/jdev/2022-07-17#2022-07-17-d81ddc5a53cd0080 -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] What to do about multi-item data forms?
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 element tells you what you searched for, and each 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 element. HTH, Peter ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] What to do about multi-item data forms?
On Sun, Jul 17, 2022, at 14:04, Peter Saint-Andre wrote: > 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". This sounds like the original intent was for this to be a separate data type that does not include fields, instructions, or title elements. >> (though there are no examples where a form contains reported/items >> and any other form element). > > The lack of examples is indeed not good. But this sounds like it should contain those other elements, so it's still not clear to me what the original intent was :) > What use cases do folks have in mind nowadays for multi-item data > forms of type 'result'? I think singpolymas example was a good one: the jmp.chat folks would like to display some form information that includes your account balance, and below that a table (aka multi-item form) of recent transactions. > Do these libraries allow multiple items in forms of type 'cancel', > 'form', and 'submit', or only 'result'? As far as I can tell aioxmpp errors if you try to create or parse a form with multiple items that is of a type other than result [1], but nbxmpp and Smack will let you parse or build a form of any type with items [2, 3]. —Sam [1]: https://github.com/horazont/aioxmpp/blob/949a91c25b550f5fa0ca84c8134c2c6f566cb094/aioxmpp/forms/xso.py#L615-L617 [2]: https://dev.gajim.org/gajim/python-nbxmpp/-/blob/master/nbxmpp/modules/dataforms.py#L710 [3]: https://github.com/igniterealtime/Smack/blob/ef003bbc5c8c47fb6f32ac78631168d4b197fe0a/smack-extensions/src/main/java/org/jivesoftware/smackx/xdata/provider/DataFormProvider.java#L69-L73 -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] What to do about multi-item data forms?
On 7/17/22 3:03 PM, Sam Whited wrote: On Sun, Jul 17, 2022, at 14:04, Peter Saint-Andre wrote: 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". This sounds like the original intent was for this to be a separate data type Could you clarify what you mean by a separate data type? Are you suggesting that, say, might have been cleaner than overloading (if that's what we did)? that does not include fields, instructions, or title elements. I believe so. But we cooked this up 20+ years ago and my memory might faulty. :-) (though there are no examples where a form contains reported/items and any other form element). The lack of examples is indeed not good. But this sounds like it should contain those other elements, so it's still not clear to me what the original intent was :) I meant the lack of examples in general, not the lack of examples of reported + items + field/instructions/title. What use cases do folks have in mind nowadays for multi-item data forms of type 'result'? I think singpolymas example was a good one: the jmp.chat folks would like to display some form information that includes your account balance, and below that a table (aka multi-item form) of recent transactions. This sounds like "reported" without a prior request. I suppose that's OK, but it seems slightly unexpected. Do these libraries allow multiple items in forms of type 'cancel', 'form', and 'submit', or only 'result'? As far as I can tell aioxmpp errors if you try to create or parse a form with multiple items that is of a type other than result [1], but nbxmpp and Smack will let you parse or build a form of any type with items [2, 3]. Interesting. I do think this was intended for use only with 'result' forms. Peter ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] What to do about multi-item data forms?
Just that forms with fields and multi-item forms can't be mixed. Ie you can have or but not . On Sun, Jul 17, 2022, at 19:02, Peter Saint-Andre wrote: > Could you clarify what you mean by a separate data type? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] What to do about multi-item data forms?
Thinking about this more, I'm not sure that it makes sense to clarify this in a new XEP. Did we ever come up with something along the lines of IETF erratas or editors notes that we could put at the beginning of the document? After re-reading this thread it's still unclear to me what the original intent was and it doesn't seem like anyone else besides Peter and I have opinions, so I'm tempted to write something that says "multi-item forms are a separate thing and can't have fields/instruction/title/etc." as that seems the simplest solution, but I'm not sure where we'd put this text. —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] What to do about multi-item data forms?
On 7/19/22 6:46 AM, Sam Whited wrote: Thinking about this more, I'm not sure that it makes sense to clarify this in a new XEP. Did we ever come up with something along the lines of IETF erratas or editors notes that we could put at the beginning of the document? We don't have errata, we have "living standards". An Editor's Note might be appropriate, or we just update XEP-0004 through the usual process even though it's Final. After re-reading this thread it's still unclear to me what the original intent was and it doesn't seem like anyone else besides Peter and I have opinions, so I'm tempted to write something that says "multi-item forms are a separate thing and can't have fields/instruction/title/etc." as that seems the simplest solution, but I'm not sure where we'd put this text. I'd put it in Section 3.4. :-) Peter ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] What to do about multi-item data forms?
On 19/07/2022 14.46, Sam Whited wrote: Thinking about this more, I'm not sure that it makes sense to clarify this in a new XEP. Did we ever come up with something along the lines of IETF erratas or editors notes that we could put at the beginning of the document? I would prefer to update the existing XEP if this is an option. I think it may be. After re-reading this thread it's still unclear to me what the original intent was and it doesn't seem like anyone else besides Peter and I have opinions, It was not so long ago when I reworked Smack's Data Form code. IIRC I was under the impression that and do *not* appear within the same data form. I believe that disallowing mixing and within the same form makes interoperability easier, as it reduces the valid possibilities how the protocol could be used. Ideally use-cases like the one mentioned (jmp.chat) can instead be build of an optional extension protocol, probably based on using two data forms. In any case, this should be clarified in the XEP. So thanks for your effort Sam! :) - Flow OpenPGP_signature Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] What to do about multi-item data forms?
Hi, While i also think that its probably better to write a note that says and should not be mixed in the same form, i dont see a good reason why we cant use and with the reported form. It does not add complexity and is useful to provide some context with the form. So if we limit the usage of the XEP lets not throw the baby out with the bathwater. Regards Philipp Am Di., 19. Juli 2022 um 21:47 Uhr schrieb Florian Schmaus : > On 19/07/2022 14.46, Sam Whited wrote: > > Thinking about this more, I'm not sure that it makes sense to clarify > > this in a new XEP. Did we ever come up with something along the lines > > of IETF erratas or editors notes that we could put at the beginning of > > the document? > > I would prefer to update the existing XEP if this is an option. I think > it may be. > > > > After re-reading this thread it's still unclear to me what the original > > intent was and it doesn't seem like anyone else besides Peter and I > > have opinions, > > It was not so long ago when I reworked Smack's Data Form code. IIRC I > was under the impression that and do *not* appear > within the same data form. > > I believe that disallowing mixing and within the same > form makes interoperability easier, as it reduces the valid > possibilities how the protocol could be used. Ideally use-cases like the > one mentioned (jmp.chat) can instead be build of an optional extension > protocol, probably based on using two data forms. > > In any case, this should be clarified in the XEP. So thanks for your > effort Sam! :) > > - Flow > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] What to do about multi-item data forms?
I agree with this in principal, however by doing this (but not allowing field) we're definitely moving beyond clarifying the text and into making normative changes. The text either meant "no elements other than item/reported are allowed in multi-part forms" or "items are allowed in forms along with everything else" so saying "item/reported/other elements are allowed, but not 'field'" would be new territory. Although it appears that at least some libraries are already doing this even though it's in violation of the spec, so maybe we'd just be updating the spec to match reality. —Sam On Tue, Jul 19, 2022, at 15:55, Philipp Hörist wrote: > Hi, > > While i also think that its probably better to write a note that says > and should not be mixed in the same form, i dont see > a good reason why we cant use and with the > reported form. > > It does not add complexity and is useful to provide some context with > the form. > > So if we limit the usage of the XEP lets not throw the baby out with > the bathwater. > > Regards Philipp > > Am Di., 19. Juli 2022 um 21:47 Uhr schrieb Florian Schmaus > >: > >> On 19/07/2022 14.46, Sam Whited wrote: >> > Thinking about this more, I'm not sure that it makes sense to >> > clarify this in a new XEP. Did we ever come up with something along >> > the lines of IETF erratas or editors notes that we could put at the >> > beginning of the document? >> >> I would prefer to update the existing XEP if this is an option. I >> think it may be. >> >> >> > After re-reading this thread it's still unclear to me what the >> > original intent was and it doesn't seem like anyone else besides >> > Peter and I have opinions, >> >> It was not so long ago when I reworked Smack's Data Form code. IIRC I >> was under the impression that and do *not* appear >> within the same data form. >> >> I believe that disallowing mixing and within the >> same form makes interoperability easier, as it reduces the valid >> possibilities how the protocol could be used. Ideally use-cases like >> the one mentioned (jmp.chat) can instead be build of an optional >> extension protocol, probably based on using two data forms. >> >> In any case, this should be clarified in the XEP. So thanks for your >> effort Sam! :) >> >> - Flow >> ___ >> Standards mailing list Info: >> https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards- >> unsubscr...@xmpp.org >> ___ >> > > ___ > Standards mailing list Info: > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards- > unsubscr...@xmpp.org > ___ -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] What to do about multi-item data forms?
I have submitted the following to try and remedy this issue: https://github.com/xsf/xeps/pull/1194 Though I don't think we came to consensus in this thread, I get the impression that not mixing and matching normal form and multi-item form elements was the original intent. For users that want to use tables in their normal forms, they could define a new XEP that standardizes a "table" field or similar later, so we're not really losing anything since as far as I know no one does this yet anyways. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
