On 5/5/20 12:35 PM, Matthew Wild wrote: > On Sat, 2 May 2020 at 21:29, Florian Schmaus <f...@geekplace.eu > <mailto:f...@geekplace.eu>> wrote: > > So why go for the slightly more complicated semantic of > list-multi+<open/>, when we could just go with text-multi? > > > We covered this somewhat in the MUC since you sent this email, but I'll > summarize here.
Thanks for taking the time to reply here. Much appreciated. :) > text-multi is defined and intended to be used for submitting a > *multi-line string*. It is not (as you might easily interpret from the > name) intended for submission of multiple independent text values. The > latter is covered by list-multi (which was evidently already found to be > restrictive by the time XEP-0122 was written and defined <open/>). That is basically the bottom of our dispute. You believe that presenting multi line strings on the UI level is the *only* reason text-multi exists. But I do not see any reason why it should not *also* be used to carry multiple text values. And there are already XEPs which use text-multi that way. See XEP-0248 for example. You seem to ignore this point. > My argument therefore is that a protocol treating text-multi as multiple > independent text values (i.e. a list of message ids) is incorrect, and > that following incorrect semantics it will cause practical problems for > libraries that expose a dataforms API that accepts/returns a multiline > string for fields of this type. Surely such API could also provide an interface to return the values of text-multi fields verbatim, i.e. as list of values, in additional to returning the values as multiline string? > As a reminder, XEP-0004 states: "an application that receives multiple > <value/> elements for a field of type "text-multi" SHOULD merge the XML > character data of the value elements into one text block for > presentation to a user, with each string separated by a newline > character as appropriate for that platform.". > > I'll dismiss the "presentation to a user" part as a consequence of data > forms initially being designed for machine<->user interaction, and not > machine<->machine interaction as has become common in the years since > the specification was written. The spirit of the specification is very > clear: text-multi represents multi-line text values. I think you can not dismiss the "presentation to a user" part, as, in my view, this clearly means what it says (and nothing more). If you display text-multi values in a UI, then display them as multiline string, each value is a line. This does not imply that you can not use text-multi for cases where usually no UI is involved, MAM in this particular case. > Your argument, as I understand it, is that a library has every right to > expose the individual text values (i.e. not do the merging mentioned in > the spec). I agree, libraries always have the ability to choose the > level of abstraction they will provide in their API. Some may just give > you the raw XML, some may process the form a little and give you the > individual <value> elements, and yet others will attempt to implement > validation, and translation to native data types. All these are valid > approaches for different kinds of library. This reads like you believe that libraries have to select exactly one way how to expose text-multi to the higher layers, which is not true. > In my case I'm dealing with at least one dataforms library that exposes > a high-level API (form XML in -> native data types out) and from that I > would receive a multiline string from a text-multi field, exactly as I > would expect. I am sure you can add a feature to this library where it will return the text-multi values verbatim as list of strings. I hope this is not an attempt to force a protocol in a certain direction to circumvent shortcomings of a particular implementation. But knowing you, I think this is not the case. Yet, I wonder if you look at this too much with a particular implementation, one wich you are very familiar with, in mind. - Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
