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

Peter Saint-Andre stpeter at mozilla.com
Wed May 13 02:40:01 UTC 2020


Hi. Florian asked me to reply, so here I am. :-)

On 5/7/20 10:00 AM, Florian Schmaus wrote:
> 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
> point.

It's true that Data Forms were defined with UI (not m2m) in mind, and
that text-multi fields were supposed to enable multi-line input,
equivalent to the HTML <textarea> element. However, if we look at all
the uses of text-multi in XEPs, it seems that we abandoned the UI focus
or "text blog" construct a long time ago. Here are some examples.

XEP-0060...

  <field var='pubsub#children'
         type='text-multi'
         label='The child nodes (leaf or collection) associated with a
collection.'/>

  <field var='pubsub#collection'
         type='text-multi'
         label='The collection(s) with which a node is affiliated'/>

XEP-0068...

  <field var="http://example.com/pubsub}time_restrictions"
         type="text-multi"
         label="Limit to these time ranges">
    <value>09:00-12:00</value>
    <value>13:00-17:00</value>
  </field>

XEP-0115...

  <field var='ip_version' type='text-multi' >
    <value>ipv4</value>
    <value>ipv6</value>
  </field>

XEP-0141...

  <field var='activity.mailing-lists' type='text-multi' label='Recent
Mailing List Activity'>
  </field>

  <field var='activity.xeps' type='text-multi' label='XEPs Authored or
Co-Authored'>
  </field>

XEP-0248...

  <field
      var='pubsub#collection'
      type='text-multi'
      label='The collections of which this node is a child'/>

  <field
      var='pubsub#children'
      type='text-multi'
      label='The nodes of which this node is a parent'/>

XEP-0326...

  <field var='fields' type='text-multi'>
    <value>Temperature</value>
    <value>Pressure</value>
    <value>Power</value>
  </field>

Although some of these specs never advanced beyond Experimental and you
could argue that they might have been "corrected" before advancing,
others are Draft standards in wide use. We might want to face reality
and allow text-multi to treat each line as semantically independent.

Peter

P.S. I realize that this inconsistency is my fault, since I authored
both XEP-0004 and specs that violate XEP-0004. Sorry about that!

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


More information about the Standards mailing list