select_one_from_file with media URLs instead of files.

[roger.h...@kimetrica.com]

I want to use select_one_from_file to allow us to centrally maintain a lookup list that we can reuse across many forms - so that when we add new entries to the lookup list we don't have to redeploy the form. Also, ideally, I'd like to be able to just have to update the central list and not have to attach the new version of it to each of the deployed forms.

In theory I can do this by specifying a media URL in Kobocat rather than a media file. e.g. I specify https://ww.example.com/lookups/funding_choices.csv as the source rather than uploading funding_choices.csv directly. If I do that then it shows up in the manifest with a filename of "https://ww.example.com/lookups/funding_choices.csv" and then the select_one_from_file doesn't work because it says the instance is invalid.

If I alter Kobocat so that manifest returns with a filename of conservancies.csv and the same URL then it works - but I doubt I will get that change accepted upstream because it would break compatibility with anyone currently using media URLs for media::image attributes on questions - where the existing approach works just fine - you can put the value for media::image as https://www.example.com/images/img1.png.

Is it reasonable to expect Enketo to handle: "select_one_from_file https://ww.example.com/lookups/funding_choices.csv"? Or even "select_one_from_file https://ww.example.com/api/v1/funding_choices.csv?used_for=donations"?

Thanks

Roger

[Martijn van de Rijdt]

Hi Roger,

I think your requirement perfectly illustrates the power of external data. Users' ability to leverage this power is still limited as you found. I think it's mostly up to the OpenRosa servers to do this. Ona made a start with this: https://help.ona.io/faq/linking-dataset-as-media-files

That seems to me to be the right approach. 1) Add a (shared) file via the Ona/Kobo/etc UI with a (fake) filename, and 2) reference this filename in the XLSForm. Step 1 could be extended by allowing adding a URL instead of a locally generated/uploaded file. That would make perfect sense to me.

Adding URL support to XLSForm (and Ona/KoBo/etc) is also an approach worth considering, but it doesn't seem as suitable to me because of the way the XForms Manifest works. 

Cheers,
Martijn

--
You received this message because you are subscribed to the Google Groups "enketo-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to enketo-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 

Revolutionizing data collection since 2012.

Enketo    |    LinkedIn    |    GitHub    |    Twitter    |    Blog

[roger.h...@kimetrica.com]

I think it's mostly up to the OpenRosa servers to do this. Ona made a start with this: https://help.ona.io/faq/linking-dataset-as-media-files

Kobocat already support attachments, and remote attachments accessed via a URL. The problem is that they don't let you choose the filename - if you upload a file it has to have the correct filename already, and if you use a remote URL the filename is always the full URL. I have logged a Kobocat Issue at https://github.com/kobotoolbox/kobocat/issues/344 to see if they will make a change to automatically extract just the filename part from a remote URL and pass that in the manifest instead, but it would be a backwards-incompatible change because people currently using remote urls with media::image would need to change their forms.

Does the XForm spec have any rules on what makes a valid instance id or attachment filename?

Roger

[Martijn van de Rijdt]

Hi Roger, 

This is the best I could find for the value constraint of an id attribute (on the instance element):

 An xsd:ID value must be an NCName. This means that it must start with a letter or underscore, and can only contain letters, digits, underscores, hyphens, and periods

(Note, that we haven't specified this yet in the ODK XForms spec.) 

In my opinion, it is best to keep the src attribute of an instance as a URL with jr:// scheme, but this is definitely debatable. I prefer to do the mapping from the jr:// scheme to a https:// URL on the side of the XFormsManifest, so we avoid cross-domain access issues. So the burden to implement this could be on the server side, on the XLSForm (pyxform) side or on both. 

XLSForm is of course very flexible. We could probably extend it in many ways, e.g. by implementing a way to add type='instance' which could then perhaps be used in conjunction with a regular select_one and select_multiple. 

Cheers,
martijn

--

You received this message because you are subscribed to the Google Groups "enketo-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to enketo-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.