remove type="select" and type="select1"?

[MartijnR]

Commcare doesn't actually do anything with this information (just treated as string). Does ODK's javarosa do anything with it?

If not, shall we remove from the spec? (any unknown type would be treated as string).

[MartijnR]

https://dimagi.github.io/xform-spec/#data-types

[MartijnR]

It's actually not mentioned under datatypes, but there are some other references to it. So either we remove entirely or add to datatypes.

I vote for removing entirely.

[lognaturel]

there are some other references to it

I only see them in the bindings section. Anywhere else?

As part of doing this, we should probably explicitly say that the bind type can be any type. This is what W3C XForms says here:

Data Binding Restrictions: Binds to any simpleContent. The restriction to binding simpleContent exists when the choices are authored as part of the user interface control as shown in this section. Element itemset (described in 9.3.6 The itemset Element) creates dynamic selection items and allows the available choices to be obtained from an XForms Model. When itemset uses the value element, the restriction to binding simpleContent remains in effect. However, the itemset also allows for the selection and deselection of subtrees of instance data using the copy element, and when using that construct, the data binding restriction to simpleContent is relaxed, but the form control must bind to an element with no mixed content.

I don't think this spec includes selection and deselection of subtrees.

[MartijnR]

That's all, I think.

[smoyte]

We use type="select1" in NEMO. Not for any particular reason, just b/c that's what the examples probably used when we first built our XML renderer.

Here is a snippet:

      <bind nodeset="/data/*itemcode2*_1" type="select1" required="true()"/>
      <bind nodeset="/data/*itemcode2*_2" type="select1"/>
      <bind nodeset="/data/*itemcode3*_1" type="select1" required="true()"/>
      <bind nodeset="/data/*itemcode3*_2" type="select1" required="true()"/>
      <bind nodeset="/data/*itemcode3*_3" type="select1" required="true()"/>
    </model>
  </h:head>
  <h:body>
    <select1 ref="/data/*itemcode1*">
      <label ref="jr:itext('*itemcode1*:label')"/>
      <hint ref="jr:itext('*itemcode1*:hint')"/>
      <item>
        <label ref="jr:itext('*optcode1*')"/>
        <value>*optcode1*</value>
      </item>
      <item>
        <label ref="jr:itext('*optcode2*')"/>
        <value>*optcode2*</value>
      </item>
    </select1>

(Don't mind the *'s in the refs, those get substituted during test runs.)

Would this continue to work in future or would we have to change something? I'm not against changing stuff to help clean up the spec. Just curious about the upgrade path/doing this without breaking stuff.

[lognaturel]

Thanks, @smoyth! Existing clients would continue to work with select1 and select bind types for backwards compatibility so it should be seamless for users of clients and form builders.

Where it becomes an issue is if analysis tools that expect the bind to identify selects get a form with a string bind and then don't do what they're supposed to do.