[Standards] form field types: text-multi vs list-multi with <validate><open/></validate>
flo at geekplace.eu
Sat May 2 20:27:21 UTC 2020
On 4/20/20 5:20 PM, Matthew Wild wrote> I have just updated the PR in
response to feedback here and in the MUC.
> - Removed the separate iq for fetching a single message by id, this is
> now done via the 'ids' field in the data form and supports multiple ids
This MAM change, diff available at
<http://geekplace.eu/xeps/xep-mam/diff.html>, uses a form field with the
type list-multi to collect the IDs of the requested messages.
I know there was a discussion if the field type should be list-multi or
text-multi. At first, the list-* types seemed unsuited, because they
carry a "please select one (list-single) or potentially multiple
(list-multi) items *from this list*" semantic. And everyone agrees that
in MAM's case, we don't want the archive to provide a list of all valid IDs.
So text-multi came into play. But someone raised concerns, that I sadly
do not remember any more.
Because of those concerns, list-multi with xep122 § 3.2.2 <open/>
validation was chosen. This would do the trick.
But, for one, it is a bit of misuse of <open/>: The <open/> validation
means that you not only can select items from the form provided list,
but also provide custom values (the latter would not be possible with
plain list-* form fields from xep4). And furthermore, I really like to
understand why text-multi is not exactly what we would need in this
case. The text-multi form type is for example also used in PubSub
(xep60) to list all children nodes of a collection node, and all
collections a node is affiliated with. So it is used to aggregate N
textual values (as opposed to text-single, which only allows at most 1
textual value). Sounds to me like a good fit for MAM message IDs.
So why go for the slightly more complicated semantic of
list-multi+<open/>, when we could just go with text-multi?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 618 bytes
Desc: OpenPGP digital signature
More information about the Standards