[Standards] form field types: text-multi vs list-multi with <validate><open/></validate>

Matthew Wild mwild1 at gmail.com
Tue May 5 10:35:06 UTC 2020


On Sat, 2 May 2020 at 21:29, Florian Schmaus <flo at 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.

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

At this point I am thoroughly convinced that text-multi would be a bad idea.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200505/3434d819/attachment.html>

More information about the Standards mailing list