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

Florian Schmaus flo at geekplace.eu
Wed May 13 12:50:37 UTC 2020

On 5/13/20 1:50 PM, Kevin Smith wrote:
> On 13 May 2020, at 03:40, Peter Saint-Andre <stpeter at mozilla.com> wrote:
>> <snip/>
>> We might want to face reality
>> and allow text-multi to treat each line as semantically independent.
> Sadly, I don’t think it would just be ‘facing reality’ to say that text-multi isn’t multi-line text - there are implementations (every library I’ve worked with, I think) that treats text-multi as a multi-line string (i.e. in support of what xep4 requires).
As soon as such a library where to implement e.g. PubSub collection
nodes, it has to expose the individual values of a text-multi field in a
robust way. And it is not like doing so would mean that you have to
loose support for what xep4 requires.

Because surely those libraries could be easily extended to expose the
text-multi values, in addition to a single multi-line string, as a list
of strings.

> I am sympathetic to the argument that we’ve gotten into a mess, but I don’t think getting out of it (given that 4 is Final) would be as simple as xep 4 changing semantics for text-multi - it’s not clear to me if that’s what being suggested, but if it is I think it would be painful.

I do not see where we change the semantics of text-multi here.

XMPP (and protocols in general) often gets criticized for being
over-engineerd and complex. And, while I do not like those who scream
"over-engineerd and complex" every two seconds, this discussion appears
to be a prime example what can go wrong.

We have currently two options to carry multiple values from A to B in
xep4 data forms:
- one that requires one XEP
  text-multi: xep4
- another one that requires *two* XEPs
  list-multi + <open/>, xep4 + xep122

Obviously text-multi, requiring only one XEP, is desirable. In fact, it
so natural that existing XEPs and ProtoXEPs in inbox/ use it for exact
that case.

Yet, there are attempts to argument that text-multi can not be used
because of some implementations do not allow for it. But I fail to see
how that can be an argument: implementations can be adjusted.
Furthermore, it appears *trivial* to extend those existing
implementations to allow for it. And that would not even break backwards
compatibility, and hence does not even need to be negotiated.

Fields of the type text-multi contain as a list of textual values. Even
if the initial motivation was to allow for portable multi-line strings,
I do not see any reason why we should not continue to use it to
transport multiple textual values (e.g., the IDs of the MAM messages we
want to retrieve).

MAM currently is a shining star of a reasonably well-designed and simple
protocol. I hope we keep it that way.

- 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/20200513/c5028164/attachment.sig>

More information about the Standards mailing list