bind for select1 nodeset is "select1" and this throws an XForms syntax error

[pwin]

bind for select1 nodeset is "select1" and this throws an XForms syntax error.

I think it should be the XML Schema data type of the value/s

This is a simple example output illustrating how XLSForms binds giving the type as "select1"

<?xml version="1.0"?>
<h:html xmlns="http://www.w3.org/2002/xforms" xmlns:ev="http://www.w3.org/2001/xml-events" xmlns:h="http://www.w3.org/1999/xhtml" xmlns:jr="http://openrosa.org/javarosa" xmlns:orx="http://openrosa.org/xforms" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <h:head>
    <h:title>foo</h:title>
    <model>
      <submission action="http://xformstest.org/cgi-bin/echoinstance.sh" method="form-data-post"/>
      <instance>
        <instance_xmlns_test id="instance_xmlns_test" xmlns="1234">
          <yes_or_no>yes</yes_or_no>
          <age/>
          <meta>
            <instanceID/>
          </meta>
        </instance_xmlns_test>
      </instance>
      <bind nodeset="/instance_xmlns_test/yes_or_no" type="select1"/>
      <bind constraint=". &gt;=18" jr:constraintMsg="Respondent must be 18 or over" nodeset="/instance_xmlns_test/age" type="int"/>
      <bind calculate="concat('uuid:', uuid())" nodeset="/instance_xmlns_test/meta/instanceID" readonly="true()" type="string"/>
    </model>
  </h:head>
  <h:body>
    <select1 ref="/instance_xmlns_test/yes_or_no">
      <label>Yes or No?</label>
      <hint>Look on the signboard</hint>
      <item>
        <label>Yes</label>
        <value>yes</value>
      </item>
      <item>
        <label>No</label>
        <value>no</value>
      </item>
    </select1>
    <input ref="/instance_xmlns_test/age">
      <label>How old are you?</label>
      <hint>Check your birth certificate</hint>
    </input>
  </h:body>
</h:html>

[MartijnR]

This probably should get type "string". Ongoing discussion: https://github.com/opendatakit/xforms-spec/issues/25

Is this error (or warning?) shown by ODK Validate?

[pwin]

Hi Martin, I don't know about the other validators, but when looking through the code this is an inappropriate type and it throws a syntax error with XSLTForms XForms processor.

Please can you point me to the but if code responsible?

Cheers

Peter

On 18 Dec 2017 8:14 pm, "Martijn van de Rijdt" notifications@github.com wrote:

This probably should be output as type "string". Ongoing discussion: opendatakit/xforms-spec#25 https://github.com/opendatakit/xforms-spec/issues/25

Is this error (or warning?) shown by ODK Validate?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/XLSForm/pyxform/issues/168#issuecomment-352544874, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBcTCOoZ4fKXj_HwfxkSXVMX9GB817Jks5tBseagaJpZM4RF-2d .

[MartijnR]

Ah yes, that's what I suspected. I saw the XLSTForms message this morning. :)

We deviate a little bit from regular XForms in this ODK ecosystem, not always for great reasons, and not always using proper name-spacing.

This issue, and the custom uuid() function issue are relatively minor and could perhaps be addressed (via contributor PRs). This one is pretty major though: https://opendatakit.github.io/xforms-spec/#a-big-deviation-with-xforms (though there is interest to fix this in pyxform: https://github.com/XLSForm/pyxform/issues/4). There are probably a few other output issues. However, I think it's a cool idea to use pyxform with a new validator for pure XForms (or maybe XLSForm with a pyxform replacement app). (I'm not a pyxform developer though).

[pwin]

XLSForms together with the PurcForms design tools and XSLTForms makes for a nice stack. Add it to exist-db or basex and setting up alpha versions of applications becomes a very short sprint

On 18 Dec 2017 8:39 pm, "Martijn van de Rijdt" notifications@github.com wrote:

Ah yes, that's what I suspected. I saw the XLSTForms message this morning. :)

We deviate a little bit from regular XForms in this ODK ecosystem, not always for great reasons, and not always using proper name-spacing.

This issue, and the custom uuid() function issue are relatively minor and could perhaps be addressed (via PRs). This one is pretty major though: https://opendatakit.github.io/xforms-spec/#a-big-deviation-with-xforms (though there is interest to fix this in pyxform: #4 https://github.com/XLSForm/pyxform/issues/4). There are probably a few other output issues. However, I think it's a cool idea to use pyxform with a new validator for pure XForms (or maybe XLSForm with a pyxform replacement app). (I'm not a pyxform developer though).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/XLSForm/pyxform/issues/168#issuecomment-352551037, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBcTFJU7wqaPUNBfEOKUiw7xpwkMjjvks5tBs2CgaJpZM4RF-2d .

[pwin]

Hi Martijn Has anyone set up a way of converting an XML Schema into an XLSForm input? Peter

On 18 December 2017 at 20:39, Martijn van de Rijdt <notifications@github.com

wrote:

Ah yes, that's what I suspected. I saw the XLSTForms message this morning. :)

We deviate a little bit from regular XForms in this ODK ecosystem, not always for great reasons, and not always using proper name-spacing.

This issue, and the custom uuid() function issue are relatively minor and could perhaps be addressed (via PRs). This one is pretty major though: https://opendatakit.github.io/xforms-spec/#a-big-deviation-with-xforms (though there is interest to fix this in pyxform: #4 https://github.com/XLSForm/pyxform/issues/4). There are probably a few other output issues. However, I think it's a cool idea to use pyxform with a new validator for pure XForms (or maybe XLSForm with a pyxform replacement app). (I'm not a pyxform developer though).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/XLSForm/pyxform/issues/168#issuecomment-352551037, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBcTFJU7wqaPUNBfEOKUiw7xpwkMjjvks5tBs2CgaJpZM4RF-2d .

[MartijnR]

Hi @pwin,

I am not aware of such a project. This confuses, and intrigues, me... What would be the source document format that produces an XLSForm?

The only use of XML Schema, I am aware of discussing in the ODK ecosystem, is to validate XForms with it, but nobody has done that yet either.

[pwin]

So the pyforms uses a set of excel spreadsheets to create the survey, the enumerations, and the submission etc. A XML Schema could be parsed to create the survey and the enumerations. This could then use the pyxforms processor to create an XForm

I think that there might be a way to use the OpenMRS and the PurcForms tools to design the XForm better.

What do you think?

Peter

On 22 December 2017 at 20:32, Martijn van de Rijdt <notifications@github.com

wrote:

Hi @pwin https://github.com/pwin,

I am not aware of such a project. This confuses, and intrigues, me... What would be the source document format that produces an XLSForm?

The only use of XML Schema, I am aware of discussing in the ODK ecosystem, is to validate XForms with it, but nobody has done that yet either.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/XLSForm/pyxform/issues/168#issuecomment-353670278, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBcTNvlF8uEek8Ju9cQuYqKeKwMJiGVks5tDBHrgaJpZM4RF-2d .

[ukanga]

If you want to contribute code to this I will suggest you start by writing a test, see some examples at https://github.com/XLSForm/pyxform/blob/master/pyxform/tests_v1/test_support_external_instances.py. The likely places to start are in xls2json.py and xls2json_backend.py.

In relation to XForm to XLSForm, we have a rudimentary implementation of XForm to JSON which in theory could get us back to the XLSForm on https://github.com/XLSForm/pyxform/blob/master/pyxform/xform2json.py.

[pwin]

Thanks for the links. Please can you help me with illustrations to get oriented with the PurcForms editor. What is the raw schema file that I see being used with that in e.g. openMRS and similar projects that use the pyxform approach?

On 8 January 2018 at 09:44, ukanga notifications@github.com wrote:

If you want to contribute code to this I will suggest you start by writing a test, see some examples at https://github.com/XLSForm/ pyxform/blob/master/pyxform/tests_v1/test_support_external_instances.py. The likely places to start are in xls2json.py and xls2json_backend.py.

In relation to XForm to XLSForm, we have a rudimentary implementation of XForm to JSON which in theory could get us back to the XLSForm on https://github.com/XLSForm/pyxform/blob/master/pyxform/xform2json.py.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/XLSForm/pyxform/issues/168#issuecomment-355920693, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBcTGHZhvlWcUpI4oYY6PVgh-6LVi6oks5tIeOEgaJpZM4RF-2d .

[lognaturel]

We discussed this at the recent ODK Convening. We agreed that the first step is to confirm whether or not Collect/JavaRosa works with a bind type of string today. @MartijnR, the existence of https://github.com/opendatakit/xforms-spec/issues/25 suggests that Enketo would be happy with that change today, is that correct?

[MartijnR]

I have just checked and Enketo is very happy with replacing select and select1 bind types to "string".

[lognaturel]

I tried simple select1 and select controls with bind type string and see no problems in Collect either. I can't think of any more complex or different case that would be worth verifying. @MartijnR, can you think of any?

<wishful_thinking>If not, that means this can be taken on immediately. @nribeka, if you're looking for a straightforward issue to take on, I think this one won't require further discussion. 🤞🤞 </wishful_thinking>

[MartijnR]

can you think of any?

Not for our beloved clients, but it may be worth checking whether the Ona/KoBo/Aggregate/Central/Elmo/Survey123/etc backends use the "select"bind type info for anything fancy wrt to displaying, exporting, analyzing multi-select data, since it was quite consistently, though spec-incompliantly, used for so long.

@jnm, @ukanga, @issa-tseng, @smoyth, @tedrick,

[lognaturel]

Indeed. Now that you mention it, I'm guessing that those bind types were introduced exactly to allow analysis tools to identify selects without having to parse the body. So this may not be such an easy change to make after all. 😖

@matthew-white @ggalmazor Do odkmeta or Briefcase use select and select1 bind types to identify selects?

[issa-tseng]

i guess my only question is whether there is semantic value in preserving select and select1. given that the <bind> nodes are philosophically the purest description of the nature of the data in XForms, it feels like there could be cases where understanding that the referenced data is of an enumerated option rather than freeform, or that it represents multiple values, could be valuable. otherwise you have to go all the way to the input control to figure that out.

then again, the frequent desire for freeform select1 probably obviates this value.

either way, this is a trivial change in Build.

[matthew-white]

odkmeta only ever reads the XLSForm, not the XForm, so it detects select fields using the type column in the XLSForm. I think that means that it's unaffected by this issue.

Would this change affect the form schema endpoint of the Central API? Right now I think Central determines that a field is select/select1 based on the bind type. We don't really use it anywhere in Central Frontend, but it does seem nice that right now the API will return { "type": "select", ... } or { "type": "select1", ... }.

[tedrick]

Survey123 is fine with the change - we try to enforce a separation between bind (data type) and body (presentation to the user) - having the bind type represent data type values reinforces this.

[lognaturel]

Aggregate does use the bind type but just to build a choice table that as far as I can tell is not used. I believe that this functionality was in anticipation of ODK-X features. Regardless, it's safe from an Aggregate perspective.

@ggalmazor Briefcase?

If we're going to make this change, it would be good to be in the upcoming major version bump. @ukanga, @jnm?

[smoyte]

@MartijnR we only use type="select1" b/c that's what we thought we were supposed to put there. :) Easy to change. Not using for anything fancy. Would just want a smooth upgrade path if this needs to get changed (i.e. folks using old versions of Collect wouldn't see errors).

[jnm]

@lognaturel, @MartijnR thanks for the heads-up! I don't foresee any problems with KoBo because we're also an XLSForm-based tool and really only output XForm for consumption by Collect and Enketo. We do, of course, have to read the XML submission responses, but this wouldn't affect that (unless I'm way off-base).

[lognaturel]

I think that Formhub/Kobo/Ona has an option to do a "wide" export of selects where instead of getting myquestion with value yes or no you'd get something like myquestion.yes and myquestion.no with a 1 or a 0 to signify which was selected. So @jnm, it sounds like this does not use the bind type to detect whether the question has choices associated with it?

[jnm]

Exactly—our implementation of that feature depends on analysis of the XLSForm before its conversion to XForm XML.