Use /form_id/... rather than /filename/... to name nodes

[prabhasp]

See documentation of issue here https://groups.google.com/d/topic/formhub-users/YyEhmii6jkU/discussion

[nathanathan]

This is a tricky situation. Ideally, I think the root node in the instance should always have the tag name "data" like in ODK Build because then we don't need to worry about users setting an invalid XML tag name. That would mean all the paths start /data/.... However, if we were to change the root tag to "data" or to the form id, that could break preexisting forms that use full xpaths rather than variable substitution. Also, I suspect changing the name of the root element would cause versioning issues in formhub and aggregate since submitted instances might come from old forms that have the wrong root element name. Using the filename as the root node isn't good because it imposes all the XML name constraints on XLSForm filenames, so it would be very nice to get away from, but I don't see a painless way to do it.

For reference these are the XML name constraints:

• Names can contain letters, numbers, and other characters
• Names cannot start with a number or punctuation character
• Names cannot start with the letters xml (or XML, or Xml, etc)
• Names cannot contain spaces

(source: http://www.w3schools.com/xml/xml_elements.asp)

[prabhasp]

The way formhub is set up, forms pre- and past-complication are very separate. So there shouldn't really be a problem with doing this (we WILL need to inform people, of course) for us. What are the issues on the aggregate side? Shall we bring in Waylon to this discussion to see if this changes things drastically there?

Otherwise, I would rather fix issues with the priority we have: make sure that we support ${} syntax for everything (such as repeat_count) rather than tell people the "right" way to refer to nodes using full xpath.

On Monday, September 17, 2012, Nathan Breit wrote:

This is a tricky situation. Ideally, I think the root node in the instance should have the tag name "data" like in ODK Build because then we don't need to worry about users setting an invalid XML tag name. That would mean all the paths start /data/.... However, if we were to change the root tag to "data" or to the form id, that could break preexisting forms that use full xpaths rather than variable substitution. Also, I suspect changing the name of the root element would cause versioning issues in formhub and aggregate since submitted instances might come from old forms that have the wrong root element name. Using the filename as the root node isn't good because it imposes all the XML name constraints on XLSForm filenames, so it would be very nice to get away from, but I don't see a painless way to do it.

For reference these are the XML name constraints:

• Names can contain letters, numbers, and other characters
• Names cannot start with a number or punctuation character
• Names cannot start with the letters xml (or XML, or Xml, etc)
• Names cannot contain spaces

(source: http://www.w3schools.com/xml/xml_elements.asp)

— Reply to this email directly or view it on GitHubhttps://github.com/modilabs/pyxform/issues/55#issuecomment-8604812.

Prabhas Pokharel http://twitter.com/prabhasp US mobile: +1 347 948 7654 skype/facebook/whatever: prabhasp

[nathanathan]

To add support for ${} syntax in the repeat_count/jr:count column you can copy the changes from this commit: https://github.com/UW-ICTD/pyxform/commit/676bf424452a1b2dcb82ddaa2df3555e7ee94642

I don't think it's possible to support ${} syntax in the default column because I don't think default values can be xpath expressions. I haven't found a definitive answer to that though, so if you can show me an example xform that uses xpath to set a question's default value I'll add support for it.

Are there any other columns ${} syntax is needed in?