Hi, On Sat, 2 May 2020 at 21:29, Florian Schmaus <[email protected]> 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. 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/>). 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. 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. 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. 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. At this point I am thoroughly convinced that text-multi would be a bad idea. Regards, Matthew
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
