I know that spaces generally can cause problems in code (or rather any kind
of whitespace character)
As such I have generally avoided using them outside of the labels column in
both the survey and choices tab when writing XLSForms.
However, in some use cases, at the aggregate/analysis/presentation level,
it would be useful if the choice name matched the choice label exactly. For
instance if you were publishing data live to Fusion tables, generating
charts or tables that end users would be expected to interpret with no
particular assistance - the labels they would see in charts / tables would
be as they appeared on the form; "Black or Black British" rather than
"BlackorBlackBritish" or to give a longer example "Yes, I have visited once
in the last 12 months" rather than "YesIhavevisitedonceinthelast12months".
Or any other shorthand naming convention you care to use.
So I decided to go against my general knowledge and give it a go. aWhen
uploading an XLS file for conversion via the main website:
I got the following error message - but was surprised to see it as a
warning (in yellow) rather than an outright failure (in red)
XForm Parse Warning: select1 question s [w b] should not contain
spaces, and are recommended not to contain apostraphes/quotation marks
Problem found at nodeset:
/html/body/select1[@appearance=horizontal][@ref=/OAFv1/CQ9]/item/value With
element
Is avoiding spaces/whitespace characters in choice names more a
recommendation than a hard "please don't ever do this!"
(If anyone has any ideas around managing naming conventions (from coding to
presentation/end users) either that would also be great to hear. I can
imagine at large volumes of data, using short choice names might save a
little bandwidth but I think the convenience would potentially outweigh the
cost in most cases?)
Underlying values were never meant to be displayed to the end user and
that's why they are limited in this way. The idea was that your
processing pipeline would convert those values to something more
meaningful. For example, odkmeta
(https://github.com/PovertyAction/odkmeta) does this for Stata
exports.
For select multiple, whitespace is a problem because those multiple
choices are delimited by whitespace. If your favorite colors are
RedColor and YellowColor, that answer is stored as "RedColor
YellowColor". If you use spaces (e.g., Red Color), then the answer is
"Red Color Yellow Color" and that means that "Color" is a selected
choice and lots of bad things will happen. For that reason, pyxforms
will throw an error if you use whitespaces in select multiples.
For select ones, whitespaces should not be a problem and that's why
pyxforms shows a warning and not an error. The warning is there
because of legacy pipelines that might assume otherwise.
My habits have been formed from the old J2ME phone days, so I only use
a-z, 0-9, hyphens and dashes for my selects. I keep them under 32
characters because that used to be a thing.
Yaw
ยทยทยท
On Thu, Dec 22, 2016 at 5:46 AM, Richard Fletcher wrote:
> I know that spaces generally can cause problems in code (or rather any kind
> of whitespace character)
>
> As such I have generally avoided using them outside of the labels column in
> both the survey and choices tab when writing XLSForms.
>
> However, in some use cases, at the aggregate/analysis/presentation level, it
> would be useful if the choice name matched the choice label exactly. For
> instance if you were publishing data live to Fusion tables, generating
> charts or tables that end users would be expected to interpret with no
> particular assistance - the labels they would see in charts / tables would
> be as they appeared on the form; "Black or Black British" rather than
> "BlackorBlackBritish" or to give a longer example "Yes, I have visited once
> in the last 12 months" rather than "YesIhavevisitedonceinthelast12months".
> Or any other shorthand naming convention you care to use.
>
> So I decided to go against my general knowledge and give it a go. aWhen
> uploading an XLS file for conversion via the main website:
> http://opendatakit.org/xiframe/
>
> I got the following error message - but was surprised to see it as a warning
> (in yellow) rather than an outright failure (in red)
>
> XForm Parse Warning: select1 question s [w b] should not contain
> spaces, and are recommended not to contain apostraphes/quotation marks
> Problem found at nodeset:
> /html/body/select1[@appearance=horizontal][@ref=/OAFv1/CQ9]/item/value With
> element
>
> Is avoiding spaces/whitespace characters in choice names more a
> recommendation than a hard "please don't ever do this!"
>
> (If anyone has any ideas around managing naming conventions (from coding to
> presentation/end users) either that would also be great to hear. I can
> imagine at large volumes of data, using short choice names might save a
> little bandwidth but I think the convenience would potentially outweigh the
> cost in most cases?)
>
> Thanks and Merry XLSMas
>
> --
> --
> Post: opendatakit@googlegroups.com
> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> Options: http://groups.google.com/group/opendatakit?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ODK Community" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to opendatakit+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.