Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
prabhasp opened this issue Sep 16, 2012 · 3 comments
Open

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

prabhasp opened this issue Sep 16, 2012 · 3 comments
Labels

Comments

@prabhasp
Copy link
Contributor

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

@nathanathan
Copy link
Contributor

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
Copy link
Contributor Author

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//issues/55#issuecomment-8604812.

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

@nathanathan
Copy link
Contributor

To add support for ${} syntax in the repeat_count/jr:count column you can copy the changes from this commit:
uw-ictd@676bf42

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants