Allowing "value" instead of "name" on XLSForm choices sheet

Folks,

pyxform's xls2json.py has "value" listed as an alias for "name" in the
header of the choices worksheet, but before the header is de-aliased
in workbook_to_json(), there is a check that complains if the column titled
"name" isn't present. Thus, the "value" alias is effectively broken.

The fact that you put internal values for multiple-choice options into a
column named "name" has been a persistent and frustrating source of
confusion for users. When I saw that "value" was a permitted alias, I was
delighted -- but then I was disappointed to find the alias broken.

We can very easily fix the error and thus allow "value" to be used instead
of "name" -- but this would cause a quite serious incompatibility between
SurveyCTO and other ODK tools unless the error were also fixed in other
tools.

If we contribute a fix to this, how would others feel about (a) adopting
the fix and (b) documenting the "value" alias on xlsform.org? I don't want
to cause unnecessary confusion and I don't know the history behind choice
of the "name" header, so I thought it best to check with all of you.

Please let me know.

Thanks,

Chris

I've always hated 'name'
Documenting and supporting both makes sense to me.

(In ODK 2.0, we use 'choice_list_name' and 'data_value' in an effort to
eliminate this same confusion)

··· On Tue, Dec 8, 2015 at 8:16 PM, Christopher Robert wrote:

Folks,

pyxform's xls2json.py has "value" listed as an alias for "name" in the
header of the choices worksheet, but before the header is de-aliased
in workbook_to_json(), there is a check that complains if the column titled
"name" isn't present. Thus, the "value" alias is effectively broken.

The fact that you put internal values for multiple-choice options into a
column named "name" has been a persistent and frustrating source of
confusion for users. When I saw that "value" was a permitted alias, I was
delighted -- but then I was disappointed to find the alias broken.

We can very easily fix the error and thus allow "value" to be used instead
of "name" -- but this would cause a quite serious incompatibility between
SurveyCTO and other ODK tools unless the error were also fixed in other
tools.

If we contribute a fix to this, how would others feel about (a) adopting
the fix and (b) documenting the "value" alias on xlsform.org? I don't
want to cause unnecessary confusion and I don't know the history behind
choice of the "name" header, so I thought it best to check with all of you.

Please let me know.

Thanks,

Chris

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

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

Sounds good to me too...

Yaw

··· -- Need ODK consultants? Nafundi provides form design, server setup, in-field training, and software development for ODK. Go to https://nafundi.com to get started.

On Wed, Dec 9, 2015 at 7:15 PM, Mitch Sundt mitchellsundt@gmail.com wrote:

I've always hated 'name'
Documenting and supporting both makes sense to me.

(In ODK 2.0, we use 'choice_list_name' and 'data_value' in an effort to
eliminate this same confusion)

On Tue, Dec 8, 2015 at 8:16 PM, Christopher Robert crobert@surveycto.com wrote:

Folks,

pyxform's xls2json.py has "value" listed as an alias for "name" in the
header of the choices worksheet, but before the header is de-aliased in
workbook_to_json(), there is a check that complains if the column titled
"name" isn't present. Thus, the "value" alias is effectively broken.

The fact that you put internal values for multiple-choice options into a
column named "name" has been a persistent and frustrating source of
confusion for users. When I saw that "value" was a permitted alias, I was
delighted -- but then I was disappointed to find the alias broken.

We can very easily fix the error and thus allow "value" to be used instead
of "name" -- but this would cause a quite serious incompatibility between
SurveyCTO and other ODK tools unless the error were also fixed in other
tools.

If we contribute a fix to this, how would others feel about (a) adopting
the fix and (b) documenting the "value" alias on xlsform.org? I don't want
to cause unnecessary confusion and I don't know the history behind choice of
the "name" header, so I thought it best to check with all of you.

Please let me know.

Thanks,

Chris

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

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

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

+1. I agree, 'value' makes more sense and should be a documented and
accepted alias.

Minor notes:

  • question "name"s need to be valid XML tag names , whereas choice list
    "name"s don't.
  • if a user has entered conflicting values under aliases for the same
    column, it should not compile.

Reviewing at the code in xls2json.py that raises this error, it is
something that I'd like to rewrite (mainly because of the nearly-extraneous
'[...]_headers' values in the workbook_dict.)

I'll have a PR fixing this problem tonight for people to review.

cheers,
-Alex

··· On Thu, Dec 10, 2015 at 3:37 AM, Yaw Anokwa wrote:

Sounds good to me too...

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Wed, Dec 9, 2015 at 7:15 PM, Mitch Sundt mitchellsundt@gmail.com wrote:

I've always hated 'name'
Documenting and supporting both makes sense to me.

(In ODK 2.0, we use 'choice_list_name' and 'data_value' in an effort to
eliminate this same confusion)

On Tue, Dec 8, 2015 at 8:16 PM, Christopher Robert < crobert@surveycto.com> wrote:

Folks,

pyxform's xls2json.py has "value" listed as an alias for "name" in the
header of the choices worksheet, but before the header is de-aliased in
workbook_to_json(), there is a check that complains if the column titled
"name" isn't present. Thus, the "value" alias is effectively broken.

The fact that you put internal values for multiple-choice options into a
column named "name" has been a persistent and frustrating source of
confusion for users. When I saw that "value" was a permitted alias, I
was

delighted -- but then I was disappointed to find the alias broken.

We can very easily fix the error and thus allow "value" to be used
instead

of "name" -- but this would cause a quite serious incompatibility
between

SurveyCTO and other ODK tools unless the error were also fixed in other
tools.

If we contribute a fix to this, how would others feel about (a) adopting
the fix and (b) documenting the "value" alias on xlsform.org? I don't
want

to cause unnecessary confusion and I don't know the history behind
choice of

the "name" header, so I thought it best to check with all of you.

Please let me know.

Thanks,

Chris

--
You received this message because you are subscribed to the Google
Groups

"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an

email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

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

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

--
Alex Dorey
415.886.7537

Wonderful! I think that new users will really benefit from this.

Alex, agreed that the code could be improved there. We were going to share
a minimal change, but if you want to do more clean-up in there then that's
great to. Please just let us know how we can help. (On this side none of us
actually know python, so we tend to make minimal changes to the code out of
necessity. If we're too ambitious, we break things.)

Thanks, all,

Chris

··· On Thu, Dec 10, 2015 at 5:53 PM Alex Dorey wrote:

+1. I agree, 'value' makes more sense and should be a documented and
accepted alias.

Minor notes:

  • question "name"s need to be valid XML tag names , whereas choice list
    "name"s don't.
  • if a user has entered conflicting values under aliases for the same
    column, it should not compile.

Reviewing at the code in xls2json.py that raises this error, it is
something that I'd like to rewrite (mainly because of the nearly-extraneous
'[...]_headers' values in the workbook_dict.)

I'll have a PR fixing this problem tonight for people to review.

cheers,
-Alex

On Thu, Dec 10, 2015 at 3:37 AM, Yaw Anokwa yanokwa@nafundi.com wrote:

Sounds good to me too...

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Wed, Dec 9, 2015 at 7:15 PM, Mitch Sundt mitchellsundt@gmail.com wrote:

I've always hated 'name'
Documenting and supporting both makes sense to me.

(In ODK 2.0, we use 'choice_list_name' and 'data_value' in an effort to
eliminate this same confusion)

On Tue, Dec 8, 2015 at 8:16 PM, Christopher Robert < crobert@surveycto.com> wrote:

Folks,

pyxform's xls2json.py has "value" listed as an alias for "name" in the
header of the choices worksheet, but before the header is de-aliased in
workbook_to_json(), there is a check that complains if the column
titled

"name" isn't present. Thus, the "value" alias is effectively broken.

The fact that you put internal values for multiple-choice options into
a

column named "name" has been a persistent and frustrating source of
confusion for users. When I saw that "value" was a permitted alias, I
was

delighted -- but then I was disappointed to find the alias broken.

We can very easily fix the error and thus allow "value" to be used
instead

of "name" -- but this would cause a quite serious incompatibility
between

SurveyCTO and other ODK tools unless the error were also fixed in other
tools.

If we contribute a fix to this, how would others feel about (a)
adopting

the fix and (b) documenting the "value" alias on xlsform.org? I don't
want

to cause unnecessary confusion and I don't know the history behind
choice of

the "name" header, so I thought it best to check with all of you.

Please let me know.

Thanks,

Chris

--
You received this message because you are subscribed to the Google
Groups

"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an

email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

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

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

--
Alex Dorey
415.886.7537

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

FYI, we're testing a minimal pyxform fix for our upcoming 2.01 maintenance
release, then in 2.10 we'll shift to using "value" as the default in our
form templates, samples, help, and form designer.

Alex, if you want us to share the minimal fix, please just let me know. I
don't want to get in the way of your broader clean-up efforts, however.

Thanks,

Chris

··· On Thu, Dec 10, 2015 at 8:39 PM Christopher Robert wrote:

Wonderful! I think that new users will really benefit from this.

Alex, agreed that the code could be improved there. We were going to share
a minimal change, but if you want to do more clean-up in there then that's
great to. Please just let us know how we can help. (On this side none of us
actually know python, so we tend to make minimal changes to the code out of
necessity. If we're too ambitious, we break things.)

Thanks, all,

Chris

On Thu, Dec 10, 2015 at 5:53 PM Alex Dorey dorey415@gmail.com wrote:

+1. I agree, 'value' makes more sense and should be a documented and
accepted alias.

Minor notes:

  • question "name"s need to be valid XML tag names , whereas choice list
    "name"s don't.
  • if a user has entered conflicting values under aliases for the same
    column, it should not compile.

Reviewing at the code in xls2json.py that raises this error, it is
something that I'd like to rewrite (mainly because of the nearly-extraneous
'[...]_headers' values in the workbook_dict.)

I'll have a PR fixing this problem tonight for people to review.

cheers,
-Alex

On Thu, Dec 10, 2015 at 3:37 AM, Yaw Anokwa yanokwa@nafundi.com wrote:

Sounds good to me too...

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Wed, Dec 9, 2015 at 7:15 PM, Mitch Sundt mitchellsundt@gmail.com wrote:

I've always hated 'name'
Documenting and supporting both makes sense to me.

(In ODK 2.0, we use 'choice_list_name' and 'data_value' in an effort to
eliminate this same confusion)

On Tue, Dec 8, 2015 at 8:16 PM, Christopher Robert < crobert@surveycto.com> wrote:

Folks,

pyxform's xls2json.py has "value" listed as an alias for "name" in the
header of the choices worksheet, but before the header is de-aliased
in

workbook_to_json(), there is a check that complains if the column
titled

"name" isn't present. Thus, the "value" alias is effectively broken.

The fact that you put internal values for multiple-choice options
into a

column named "name" has been a persistent and frustrating source of
confusion for users. When I saw that "value" was a permitted alias, I
was

delighted -- but then I was disappointed to find the alias broken.

We can very easily fix the error and thus allow "value" to be used
instead

of "name" -- but this would cause a quite serious incompatibility
between

SurveyCTO and other ODK tools unless the error were also fixed in
other

tools.

If we contribute a fix to this, how would others feel about (a)
adopting

the fix and (b) documenting the "value" alias on xlsform.org? I
don't want

to cause unnecessary confusion and I don't know the history behind
choice of

the "name" header, so I thought it best to check with all of you.

Please let me know.

Thanks,

Chris

--
You received this message because you are subscribed to the Google
Groups

"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an

email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

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

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

--
Alex Dorey
415.886.7537

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

Hi Chris,
Sorry I didn't send an update on this but I did make progress on it.
I found (and you probably did too) that deleting this code
https://github.com/XLSForm/pyxform/compare/issue-54#diff-b29aeb282b118614b8333cdfc19f700dL264
in xls2json.py fixes the problem.
The one feature that it breaks is the ability to warn users when they
forgot to include the first row of the xlsform with the column headers.
However, the rest of the xform generation goes smoothly and validation
takes place at a later stage.

I wrote some tests too which verify the validation does indeed take place.

Here's the branch where I have it up--
https://github.com/XLSForm/pyxform/compare/issue-54

··· On Fri, Dec 11, 2015 at 10:45 PM, Christopher Robert wrote:

FYI, we're testing a minimal pyxform fix for our upcoming 2.01 maintenance
release, then in 2.10 we'll shift to using "value" as the default in our
form templates, samples, help, and form designer.

Alex, if you want us to share the minimal fix, please just let me know. I
don't want to get in the way of your broader clean-up efforts, however.

Thanks,

Chris

On Thu, Dec 10, 2015 at 8:39 PM Christopher Robert crobert@surveycto.com wrote:

Wonderful! I think that new users will really benefit from this.

Alex, agreed that the code could be improved there. We were going to
share a minimal change, but if you want to do more clean-up in there then
that's great to. Please just let us know how we can help. (On this side
none of us actually know python, so we tend to make minimal changes to the
code out of necessity. If we're too ambitious, we break things.)

Thanks, all,

Chris

On Thu, Dec 10, 2015 at 5:53 PM Alex Dorey dorey415@gmail.com wrote:

+1. I agree, 'value' makes more sense and should be a documented and
accepted alias.

Minor notes:

  • question "name"s need to be valid XML tag names , whereas choice list
    "name"s don't.
  • if a user has entered conflicting values under aliases for the same
    column, it should not compile.

Reviewing at the code in xls2json.py that raises this error, it is
something that I'd like to rewrite (mainly because of the nearly-extraneous
'[...]_headers' values in the workbook_dict.)

I'll have a PR fixing this problem tonight for people to review.

cheers,
-Alex

On Thu, Dec 10, 2015 at 3:37 AM, Yaw Anokwa yanokwa@nafundi.com wrote:

Sounds good to me too...

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Wed, Dec 9, 2015 at 7:15 PM, Mitch Sundt mitchellsundt@gmail.com wrote:

I've always hated 'name'
Documenting and supporting both makes sense to me.

(In ODK 2.0, we use 'choice_list_name' and 'data_value' in an effort
to
eliminate this same confusion)

On Tue, Dec 8, 2015 at 8:16 PM, Christopher Robert < crobert@surveycto.com> wrote:

Folks,

pyxform's xls2json.py has "value" listed as an alias for "name" in
the

header of the choices worksheet, but before the header is de-aliased
in

workbook_to_json(), there is a check that complains if the column
titled

"name" isn't present. Thus, the "value" alias is effectively broken.

The fact that you put internal values for multiple-choice options
into a

column named "name" has been a persistent and frustrating source of
confusion for users. When I saw that "value" was a permitted alias,
I was

delighted -- but then I was disappointed to find the alias broken.

We can very easily fix the error and thus allow "value" to be used
instead

of "name" -- but this would cause a quite serious incompatibility
between

SurveyCTO and other ODK tools unless the error were also fixed in
other

tools.

If we contribute a fix to this, how would others feel about (a)
adopting

the fix and (b) documenting the "value" alias on xlsform.org? I
don't want

to cause unnecessary confusion and I don't know the history behind
choice of

the "name" header, so I thought it best to check with all of you.

Please let me know.

Thanks,

Chris

--
You received this message because you are subscribed to the Google
Groups

"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an

email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

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

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

--
Alex Dorey
415.886.7537

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

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

--
Alex Dorey
415.886.7537

Great!

I had just tweaked the check to require one "list_name" or "list name" and
one "name" or "value", otherwise give the warning. That maintained the
desired behavior, but allowing the alias. Your fix looks much more
thorough, though, including the tests.

Thanks!

Chris

··· On Sat, Dec 12, 2015 at 11:17 AM Alex Dorey wrote:

Hi Chris,
Sorry I didn't send an update on this but I did make progress on it.
I found (and you probably did too) that deleting this code
https://github.com/XLSForm/pyxform/compare/issue-54#diff-b29aeb282b118614b8333cdfc19f700dL264
in xls2json.py fixes the problem.
The one feature that it breaks is the ability to warn users when they
forgot to include the first row of the xlsform with the column headers.
However, the rest of the xform generation goes smoothly and validation
takes place at a later stage.

I wrote some tests too which verify the validation does indeed take place.

Here's the branch where I have it up--
https://github.com/XLSForm/pyxform/compare/issue-54

On Fri, Dec 11, 2015 at 10:45 PM, Christopher Robert < crobert@surveycto.com> wrote:

FYI, we're testing a minimal pyxform fix for our upcoming 2.01
maintenance release, then in 2.10 we'll shift to using "value" as the
default in our form templates, samples, help, and form designer.

Alex, if you want us to share the minimal fix, please just let me know. I
don't want to get in the way of your broader clean-up efforts, however.

Thanks,

Chris

On Thu, Dec 10, 2015 at 8:39 PM Christopher Robert crobert@surveycto.com wrote:

Wonderful! I think that new users will really benefit from this.

Alex, agreed that the code could be improved there. We were going to
share a minimal change, but if you want to do more clean-up in there then
that's great to. Please just let us know how we can help. (On this side
none of us actually know python, so we tend to make minimal changes to the
code out of necessity. If we're too ambitious, we break things.)

Thanks, all,

Chris

On Thu, Dec 10, 2015 at 5:53 PM Alex Dorey dorey415@gmail.com wrote:

+1. I agree, 'value' makes more sense and should be a documented and
accepted alias.

Minor notes:

  • question "name"s need to be valid XML tag names , whereas choice
    list "name"s don't.
  • if a user has entered conflicting values under aliases for the same
    column, it should not compile.

Reviewing at the code in xls2json.py that raises this error, it is
something that I'd like to rewrite (mainly because of the nearly-extraneous
'[...]_headers' values in the workbook_dict.)

I'll have a PR fixing this problem tonight for people to review.

cheers,
-Alex

On Thu, Dec 10, 2015 at 3:37 AM, Yaw Anokwa yanokwa@nafundi.com wrote:

Sounds good to me too...

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Wed, Dec 9, 2015 at 7:15 PM, Mitch Sundt mitchellsundt@gmail.com wrote:

I've always hated 'name'
Documenting and supporting both makes sense to me.

(In ODK 2.0, we use 'choice_list_name' and 'data_value' in an effort
to
eliminate this same confusion)

On Tue, Dec 8, 2015 at 8:16 PM, Christopher Robert < crobert@surveycto.com> wrote:

Folks,

pyxform's xls2json.py has "value" listed as an alias for "name" in
the

header of the choices worksheet, but before the header is
de-aliased in

workbook_to_json(), there is a check that complains if the column
titled

"name" isn't present. Thus, the "value" alias is effectively broken.

The fact that you put internal values for multiple-choice options
into a

column named "name" has been a persistent and frustrating source of
confusion for users. When I saw that "value" was a permitted alias,
I was

delighted -- but then I was disappointed to find the alias broken.

We can very easily fix the error and thus allow "value" to be used
instead

of "name" -- but this would cause a quite serious incompatibility
between

SurveyCTO and other ODK tools unless the error were also fixed in
other

tools.

If we contribute a fix to this, how would others feel about (a)
adopting

the fix and (b) documenting the "value" alias on xlsform.org? I
don't want

to cause unnecessary confusion and I don't know the history behind
choice of

the "name" header, so I thought it best to check with all of you.

Please let me know.

Thanks,

Chris

--
You received this message because you are subscribed to the Google
Groups

"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an

email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

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

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

--
Alex Dorey
415.886.7537

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

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

--
Alex Dorey
415.886.7537

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

Yeah. Either way works.
I have an ulterior motive of building out the tests_v1 directory
https://github.com/XLSForm/pyxform/tree/master/pyxform/tests_v1 in the
new format that clearly defines the input and expectations of each xlsform
without referencing external XLS files. In the long run, I think it will
help us make changes to the code without needing to modify dozens of
unrelated test files.

Here's the GH issue with a little bit of discussion about the tests
https://github.com/XLSForm/pyxform/pull/28#issuecomment-76719277
and
here's an example of some of the tests rewritten in the new format
https://github.com/XLSForm/pyxform/pull/49/files .

··· On Sat, Dec 12, 2015 at 11:20 AM, Christopher Robert wrote:

Great!

I had just tweaked the check to require one "list_name" or "list name" and
one "name" or "value", otherwise give the warning. That maintained the
desired behavior, but allowing the alias. Your fix looks much more
thorough, though, including the tests.

Thanks!

Chris

On Sat, Dec 12, 2015 at 11:17 AM Alex Dorey dorey415@gmail.com wrote:

Hi Chris,
Sorry I didn't send an update on this but I did make progress on it.
I found (and you probably did too) that deleting this code
https://github.com/XLSForm/pyxform/compare/issue-54#diff-b29aeb282b118614b8333cdfc19f700dL264
in xls2json.py fixes the problem.
The one feature that it breaks is the ability to warn users when they
forgot to include the first row of the xlsform with the column headers.
However, the rest of the xform generation goes smoothly and validation
takes place at a later stage.

I wrote some tests too which verify the validation does indeed take place.

Here's the branch where I have it up--
https://github.com/XLSForm/pyxform/compare/issue-54

On Fri, Dec 11, 2015 at 10:45 PM, Christopher Robert < crobert@surveycto.com> wrote:

FYI, we're testing a minimal pyxform fix for our upcoming 2.01
maintenance release, then in 2.10 we'll shift to using "value" as the
default in our form templates, samples, help, and form designer.

Alex, if you want us to share the minimal fix, please just let me know.
I don't want to get in the way of your broader clean-up efforts, however.

Thanks,

Chris

On Thu, Dec 10, 2015 at 8:39 PM Christopher Robert < crobert@surveycto.com> wrote:

Wonderful! I think that new users will really benefit from this.

Alex, agreed that the code could be improved there. We were going to
share a minimal change, but if you want to do more clean-up in there then
that's great to. Please just let us know how we can help. (On this side
none of us actually know python, so we tend to make minimal changes to the
code out of necessity. If we're too ambitious, we break things.)

Thanks, all,

Chris

On Thu, Dec 10, 2015 at 5:53 PM Alex Dorey dorey415@gmail.com wrote:

+1. I agree, 'value' makes more sense and should be a documented and
accepted alias.

Minor notes:

  • question "name"s need to be valid XML tag names , whereas choice
    list "name"s don't.
  • if a user has entered conflicting values under aliases for the same
    column, it should not compile.

Reviewing at the code in xls2json.py that raises this error, it is
something that I'd like to rewrite (mainly because of the nearly-extraneous
'[...]_headers' values in the workbook_dict.)

I'll have a PR fixing this problem tonight for people to review.

cheers,
-Alex

On Thu, Dec 10, 2015 at 3:37 AM, Yaw Anokwa yanokwa@nafundi.com wrote:

Sounds good to me too...

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Wed, Dec 9, 2015 at 7:15 PM, Mitch Sundt mitchellsundt@gmail.com wrote:

I've always hated 'name'
Documenting and supporting both makes sense to me.

(In ODK 2.0, we use 'choice_list_name' and 'data_value' in an
effort to
eliminate this same confusion)

On Tue, Dec 8, 2015 at 8:16 PM, Christopher Robert < crobert@surveycto.com> wrote:

Folks,

pyxform's xls2json.py has "value" listed as an alias for "name" in
the

header of the choices worksheet, but before the header is
de-aliased in

workbook_to_json(), there is a check that complains if the column
titled

"name" isn't present. Thus, the "value" alias is effectively
broken.

The fact that you put internal values for multiple-choice options
into a

column named "name" has been a persistent and frustrating source of
confusion for users. When I saw that "value" was a permitted
alias, I was

delighted -- but then I was disappointed to find the alias broken.

We can very easily fix the error and thus allow "value" to be used
instead

of "name" -- but this would cause a quite serious incompatibility
between

SurveyCTO and other ODK tools unless the error were also fixed in
other

tools.

If we contribute a fix to this, how would others feel about (a)
adopting

the fix and (b) documenting the "value" alias on xlsform.org? I
don't want

to cause unnecessary confusion and I don't know the history behind
choice of

the "name" header, so I thought it best to check with all of you.

Please let me know.

Thanks,

Chris

--
You received this message because you are subscribed to the Google
Groups

"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an

email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

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

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

--
Alex Dorey
415.886.7537

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

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

--
Alex Dorey
415.886.7537

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

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

--
Alex Dorey
415.886.7537

Sounds great. I'm just excited about "value". Now I wish we'd fixed that
ages ago!

Chris

··· On Sun, Dec 13, 2015, 4:40 AM Alex Dorey wrote:

Yeah. Either way works.
I have an ulterior motive of building out the tests_v1 directory
https://github.com/XLSForm/pyxform/tree/master/pyxform/tests_v1 in the
new format that clearly defines the input and expectations of each xlsform
without referencing external XLS files. In the long run, I think it will
help us make changes to the code without needing to modify dozens of
unrelated test files.

Here's the GH issue with a little bit of discussion about the tests
https://github.com/XLSForm/pyxform/pull/28#issuecomment-76719277
and
here's an example of some of the tests rewritten in the new format
https://github.com/XLSForm/pyxform/pull/49/files .

On Sat, Dec 12, 2015 at 11:20 AM, Christopher Robert < crobert@surveycto.com> wrote:

Great!

I had just tweaked the check to require one "list_name" or "list name"
and one "name" or "value", otherwise give the warning. That maintained the
desired behavior, but allowing the alias. Your fix looks much more
thorough, though, including the tests.

Thanks!

Chris

On Sat, Dec 12, 2015 at 11:17 AM Alex Dorey dorey415@gmail.com wrote:

Hi Chris,
Sorry I didn't send an update on this but I did make progress on it.
I found (and you probably did too) that deleting this code
https://github.com/XLSForm/pyxform/compare/issue-54#diff-b29aeb282b118614b8333cdfc19f700dL264
in xls2json.py fixes the problem.
The one feature that it breaks is the ability to warn users when they
forgot to include the first row of the xlsform with the column headers.
However, the rest of the xform generation goes smoothly and validation
takes place at a later stage.

I wrote some tests too which verify the validation does indeed take
place.

Here's the branch where I have it up--
https://github.com/XLSForm/pyxform/compare/issue-54

On Fri, Dec 11, 2015 at 10:45 PM, Christopher Robert < crobert@surveycto.com> wrote:

FYI, we're testing a minimal pyxform fix for our upcoming 2.01
maintenance release, then in 2.10 we'll shift to using "value" as the
default in our form templates, samples, help, and form designer.

Alex, if you want us to share the minimal fix, please just let me know.
I don't want to get in the way of your broader clean-up efforts, however.

Thanks,

Chris

On Thu, Dec 10, 2015 at 8:39 PM Christopher Robert < crobert@surveycto.com> wrote:

Wonderful! I think that new users will really benefit from this.

Alex, agreed that the code could be improved there. We were going to
share a minimal change, but if you want to do more clean-up in there then
that's great to. Please just let us know how we can help. (On this side
none of us actually know python, so we tend to make minimal changes to the
code out of necessity. If we're too ambitious, we break things.)

Thanks, all,

Chris

On Thu, Dec 10, 2015 at 5:53 PM Alex Dorey dorey415@gmail.com wrote:

+1. I agree, 'value' makes more sense and should be a documented and
accepted alias.

Minor notes:

  • question "name"s need to be valid XML tag names , whereas choice
    list "name"s don't.
  • if a user has entered conflicting values under aliases for the same
    column, it should not compile.

Reviewing at the code in xls2json.py that raises this error, it is
something that I'd like to rewrite (mainly because of the nearly-extraneous
'[...]_headers' values in the workbook_dict.)

I'll have a PR fixing this problem tonight for people to review.

cheers,
-Alex

On Thu, Dec 10, 2015 at 3:37 AM, Yaw Anokwa yanokwa@nafundi.com wrote:

Sounds good to me too...

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Wed, Dec 9, 2015 at 7:15 PM, Mitch Sundt mitchellsundt@gmail.com wrote:

I've always hated 'name'
Documenting and supporting both makes sense to me.

(In ODK 2.0, we use 'choice_list_name' and 'data_value' in an
effort to
eliminate this same confusion)

On Tue, Dec 8, 2015 at 8:16 PM, Christopher Robert < crobert@surveycto.com> wrote:

Folks,

pyxform's xls2json.py has "value" listed as an alias for "name"
in the

header of the choices worksheet, but before the header is
de-aliased in

workbook_to_json(), there is a check that complains if the column
titled

"name" isn't present. Thus, the "value" alias is effectively
broken.

The fact that you put internal values for multiple-choice options
into a

column named "name" has been a persistent and frustrating source
of

confusion for users. When I saw that "value" was a permitted
alias, I was

delighted -- but then I was disappointed to find the alias broken.

We can very easily fix the error and thus allow "value" to be
used instead

of "name" -- but this would cause a quite serious incompatibility
between

SurveyCTO and other ODK tools unless the error were also fixed in
other

tools.

If we contribute a fix to this, how would others feel about (a)
adopting

the fix and (b) documenting the "value" alias on xlsform.org? I
don't want

to cause unnecessary confusion and I don't know the history
behind choice of

the "name" header, so I thought it best to check with all of you.

Please let me know.

Thanks,

Chris

--
You received this message because you are subscribed to the
Google Groups

"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an

email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

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

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

--
Alex Dorey
415.886.7537

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

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

--
Alex Dorey
415.886.7537

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

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

--
Alex Dorey
415.886.7537

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