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 > <fields> and <items> should not be mixed in the same form, i dont see > a good reason why we cant use <instructions> and <title> 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 > <[email protected] >>: > >> 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 <item/> and <field/> do *not* appear >> within the same data form. >> >> I believe that disallowing mixing <item/> and <field/> 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- >> [email protected] >> _______________________________________________ >> > > _______________________________________________ > Standards mailing list Info: > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards- > [email protected] > _______________________________________________ -- Sam Whited _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
