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

Florian Schmaus flo at geekplace.eu
Thu May 7 16:00:03 UTC 2020

On 5/5/20 12:35 PM, Matthew Wild wrote:
> On Sat, 2 May 2020 at 21:29, Florian Schmaus <flo at geekplace.eu
> <mailto: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.

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

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200507/d87869eb/attachment.sig>

More information about the Standards mailing list