This should reference the '.' of the primary instance (at the moment, there is one known variance http://code.google.com/p/opendatakit/issues/detail?id=1070&start=300 ).

It is useful when you need to refer to '.' in the primary instance from within a filter condition being applied to a secondary instance.

A surprise addition...

this is 1-based, not 0-based

This is not correct:

A bind always refers to a single leaf node in the primary instance

It can also refer to a group or repeat node.

I have a multiple select question in ODK, I want a user to select any number of options and then be able to give answers to those questions. Based on those chosen questions, I want to calculate the total. Its seeming impossible to crack even with most answers as default.
How can we solve this problem?

Can somebody else contribute this perhaps?

https://github.com/dimagi/xform-spec

enketo/enketo#461

after #33

I think the only restriction is spaces for a select and for this reason strongly recommending to apply the same no-whitespace-restriction to select1 option values (so that a select1 could easily be changed into a select).

doesn't seem to be accepted by ODK Validate => https://docs.google.com/spreadsheets/d/13-FzLr0cmG-kaAZTXuz2MB1HMv-MJrtzafJLTkmq3Xw/edit?usp=sharing

Originally reported on Google Code with ID 1044

When working on the ODK spec, I noticed that min() and max() only accept the NodeSetType
for the first argument (or am I misreading?).

Would seems worthwhile (and easy enough) to change this to allow any argument to be
of NodeSetType. This would make it conform to XPath 2.0: http://www.w3.org/TR/xpath-functions/#func-max

Already the case in Enketo.

Reported by [email protected] on 2014-08-14 21:36:58

http://xlsform.org/#pre-loading-csv-data discusses the pulldata() function and the search() appearance for select and select1 fields. The XForm support directly follows (pulldata() as a supported function and search() as a supported appearance for select and select1).

From the discussion at getodk/collect#266, this repo does not contain the definitive spec for ODK Collect's XForms implementation. The documentation does have a note at the top, reading

Work in Progress - Pending peer-review and approval

It would be great to add a link in the same place to the definitive spec at https://bitbucket.org/javarosa/javarosa/wiki/xform

De-duplicating values can be helpful to do things like generating random numbers without duplicates as described in this mailing list thread.

SurveyCTO has shared implementations for several useful functions here including de-duplicate() which takes two strings as parameters: a delimiter and a string to de-duplicate. For example, passing in "," and "value1,value2,value1" gives "value1,value2" as its result.

XPath 2.0 defines a function called distinct-values which operates on a sequence.

It does not appear that Dimagi-xforms includes this functionality.

<bind nodeset="/data/my_question" type="string" saveIncomplete="true()" />

see http://nafundi.com/blog/posts/increasing-data-safety-in-odk-collect-with-delete-after-send-and-forced-form-save/

Seems this one doesn't exist

Not sure where I found preload "instance:. Maybe in JavaRosa code?

It might be useful to specify the file formats and any other requirements that need to be considered in order to include media in forms.

Would like to come up with a more XForms and XPath-compliant way of doing this. Will propose something if nobody beats me to it.

Expand spec by explaining what kind of number these convert to. Seconds? Milliseconds?

E.g. can it be readonly="/path/to/node = 'thisvalue'" and will be dynamically updated when /path/to/node changes?

Under Data Types, we should specify that by default text entries are limited to 255 characters, and that it can be overridden in the XML (at least for Collect):

<bind nodeset="/nm/repeat_observation/notes" type="string" odk:length="600"/>

https://groups.google.com/d/topic/opendatakit/2lcMAMnGoTE/discussion

Either this was corrected in pyxform or I made a mistake adding that slash in the spec.

correct: xmlns:orx="http://openrosa.org/xforms"

thanks @tinok

Also described here from an ODK Collect perspective and in an old wider discussion here.

As in https://dimagi.github.io/xform-spec/#secondary-instances---external, this feature just adds support for src attribute on a secondary instance and a jr://file connector for the src value.

<instance src="jr://file/countries.xml" />

I propose to start with only supporting the jr://file connector for now, and then build upon this feature in the future (e.g. by adding CSV support). This means the same resource retrieval method as jr://image, jr://audio and jr://video can be used.

Until now there is no proper agreement to add external data. This addition would not require re-inventing the wheel and as a bonus brings us closer to CommCare, raising the prospect for future compatibility.

The OpenRosa XForm Doc formed the basis of this spec but this is not mentioned anywhere.

ODK and SurveyCTO both support a once() function now, most often used with random() like so:

once(random())

The idea is that only one value is generated per form instance; once the form has a value, it maintains that value rather than replacing it. once() takes one parameter (a function call or expression).

Without this function, for example, random() was inappropriate for randomizing survey elements because the random draw would be re-calculated periodically (and, certainly, when saving and then editing). once() is also helpful when, e.g., capturing the date and time when a part of the survey is first reached. There may be other potential uses as well.

Intro refers mostly to primary instance currently.

Also needs sample with secondary instances.

The barcode data type is currently listed as "string consisting only of alphanumeric characters". However, using QR codes some users are undoubtedly storing URLs and other strings that contain non-alphanumeric characters. Is there a reason to restrict the barcode datatype to alphanumeric?

log10: https://www.w3.org/TR/2014/REC-xpath-functions-30-20140408/#func-math-log10
sin: https://www.w3.org/TR/2014/REC-xpath-functions-30-20140408/#func-math-sin
cos: https://www.w3.org/TR/2014/REC-xpath-functions-30-20140408/#func-math-cos
tan: https://www.w3.org/TR/2014/REC-xpath-functions-30-20140408/#func-math-tan
asin: https://www.w3.org/TR/2014/REC-xpath-functions-30-20140408/#func-math-asin
acos: https://www.w3.org/TR/2014/REC-xpath-functions-30-20140408/#func-math-acos
atan: https://www.w3.org/TR/2014/REC-xpath-functions-30-20140408/#func-math-atan
atan2: https://www.w3.org/TR/2014/REC-xpath-functions-30-20140408/#func-math-atan2
sqrt: https://www.w3.org/TR/2014/REC-xpath-functions-30-20140408/#func-math-sqrt
exp: https://www.w3.org/TR/2014/REC-xpath-functions-30-20140408/#func-math-exp
pi: https://www.w3.org/TR/2014/REC-xpath-functions-30-20140408/#func-math-sqrt

see https://groups.google.com/forum/#!topic/opendatakit-developers/nN8HTA5pUIM

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).

see commcare's spec for correct description

Originally reported on Google Code with ID 1034

What steps will reproduce the problem?
1. Upload attached form on http://opendatakit.org/use/xlsform/


What is the expected output? What do you see instead?

Successful transformation to XForm expected. Instead get this error: 

Error: ODK Validate Errors:
org.javarosa.core.log.WrappedException: Error evaluating field 'a': No storage factory
has been set; I don't know what kind of storage utility to create. Either set a storage
factory, or register your StorageUtilitys directly. => java.lang.RuntimeException[No
storage factory has been set; I don't know what kind of storage utility to create.
Either set a storage factory, or register your StorageUtilitys directly.]

What version of the product are you using? On what operating system?
latest on http://opendatakit.org/use/xlsform/ (also seen on ona.io)

Reported by [email protected] on 2014-07-22 20:12:33

Would love to make the metadata functionality more elegant, using the fact that generating metadata should follow a pre-defined algorithm in all clients (e.g. instanceID is always 'uuid:'+uuid()).

Is metadata currently always (or almost always) placed inside a <meta> block as direct child of the root node?

@mitchellsundt wrote:

If supplied, the one in the form is used.
Otherwise, the one in General Settings is used.

(Not supported in Enketo)

according to final agreeement here: https://groups.google.com/forum/#!topic/opendatakit-developers/wqFe7JpO9ZI

TL/DR:

<submission orx:auto-submit="false">