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