We are exploring the idea of adding a "code" column to XLS Forms.
The idea is to be able to code medical concept ids or things like HXL tags
into forms.
First, I just wanted to see if the community had an issue with this
approach.
Ie) should we use a new column or should we just use a label instead. ie)
label:code
Second, should we use code or another word like concept?
Thanks,
Matt
Matt,
You can already add arbitrary columns to XLSForms and they will be
passed through to the XML, so there is nothing preventing you from
doing this already.
If the goal is to get this new column as something that's standard in
all forms, then I think there needs to be a longer discussion around
what high level problem you are trying to solve and why you think this
solution is generic and ideal.
Yaw
On Sun, Feb 15, 2015 at 1:18 PM, Matt Berg mlberg@gmail.com wrote:
We are exploring the idea of adding a "code" column to XLS Forms.
The idea is to be able to code medical concept ids or things like HXL tags
into forms.First, I just wanted to see if the community had an issue with this
approach.Ie) should we use a new column or should we just use a label instead. ie)
label:codeSecond, should we use code or another word like concept?
Thanks,
Matt
--
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.
Yaw,
Thanks that's very helpful.
Higher level problem is we want to create forms that can map to openmrs
concept ids. Another use case is tagging for things like hxl tags.
We could use the name space for these but this makes forms non human
readable. Also, there may be cases there you just want to code a subset
of values in a form and do this retrospectively.
Code to me seems like a term that would work well but am open to other
suggestions. I could also see allowing people to do things like code:hxl
code:iso9 (Two columns) if people wanted to use more then one coding
standard in form or just to provide a bit more detail what coding approach
is being used.
We would like to standardize this approach as we will build tools around
this. Ie) data export that supports hxl.
Note we will need to include codes on options tab too.
Thoughts everyone?
Matt
Matt,
You can already add arbitrary columns to XLSForms and they will be
passed through to the XML, so there is nothing preventing you from
doing this already.https://github.com/XLSForm/pyxform/commit/ac2d3811822c533f9ac1b18315ef6cfabf816fe3
If the goal is to get this new column as something that's standard in
all forms, then I think there needs to be a longer discussion around
what high level problem you are trying to solve and why you think this
solution is generic and ideal.Yaw
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.On Sun, Feb 15, 2015 at 1:18 PM, Matt Berg mlberg@gmail.com wrote:
We are exploring the idea of adding a "code" column to XLS Forms.
The idea is to be able to code medical concept ids or things like HXL
tags
into forms.First, I just wanted to see if the community had an issue with this
approach.Ie) should we use a new column or should we just use a label instead.
ie)
label:codeSecond, should we use code or another word like concept?
Thanks,
Matt
--
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.
Hi Matt,
It's a good idea to sort out a method of including form- and field-specific
export options. With so many different ways of exporting data from ODK
systems, the method we've been using -- configure all export options on the
exporting computer -- is probably not idea. I could see a different state
of the world where the form itself has everything needed to know how to
export it.
"code" seems to me a little generic, though, and could refer to any number
of things. What if we started using an "export:" prefix followed by
different things for different export systems? So we might have
"export:stata:x", "export:googleearth:y", and "export:hxl:z".
Ideally, we'd support export-related columns both on the survey sheet and
on the settings sheet (for field-specific and form-wide export options
respectively).
Best,
Chris
Yaw,
Thanks that's very helpful.
Higher level problem is we want to create forms that can map to openmrs
concept ids. Another use case is tagging for things like hxl tags.We could use the name space for these but this makes forms non human
readable. Also, there may be cases there you just want to code a subset
of values in a form and do this retrospectively.Code to me seems like a term that would work well but am open to other
suggestions. I could also see allowing people to do things like code:hxl
code:iso9 (Two columns) if people wanted to use more then one coding
standard in form or just to provide a bit more detail what coding approach
is being used.We would like to standardize this approach as we will build tools around
this. Ie) data export that supports hxl.Note we will need to include codes on options tab too.
Thoughts everyone?
Matt
On Feb 15, 2015 11:27 PM, "Yaw Anokwa" yanokwa@nafundi.com wrote:Matt,
You can already add arbitrary columns to XLSForms and they will be
passed through to the XML, so there is nothing preventing you from
doing this already.https://github.com/XLSForm/pyxform/commit/ac2d3811822c533f9ac1b18315ef6cfabf816fe3
If the goal is to get this new column as something that's standard in
all forms, then I think there needs to be a longer discussion around
what high level problem you are trying to solve and why you think this
solution is generic and ideal.Yaw
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.On Sun, Feb 15, 2015 at 1:18 PM, Matt Berg mlberg@gmail.com wrote:
We are exploring the idea of adding a "code" column to XLS Forms.
The idea is to be able to code medical concept ids or things like HXL
tags
into forms.First, I just wanted to see if the community had an issue with this
approach.Ie) should we use a new column or should we just use a label instead.
ie)
label:codeSecond, should we use code or another word like concept?
Thanks,
Matt
--
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.--
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.
Seems fine to me to add attributes to primary XML instance nodes and
leave those attributes unchanged when submitting a record. I think the
actual exporting/transforming to a particular format is something that the
client should not concern itself with. This should be up to the server
after receiving the submission.
If we foresee a need for multiple formats in the future, using a generic
code: (or something else) namespace, as Matt suggested (so code:hxl=""),
would be sensible, since it seems unlikely we'd want to add several
different coding formats to the same form. We should define the namespace
and the different formats in the XForm spec, so the forms can be moved. Not
sure what namespace url we should use.
Matt, the use case does not include adding codes to values (e.g. select one
values), right? That would be a different story...
Cheers,
Martijn
Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/
I am unclear where these new attributes would live....
They could be on the s or within the submission instance XML
(declared within the main ).
If they are within the then you could use XLSTs to transform
things (I think this is what Martijn is envisioning?)
If they are within the then it is up to the hosting system to
interpret these attributes and handle them as it sees fit.
Note that the namespace alias ('code' or 'export') is arbitrary. The
namespace URI is what should be compared when coding.
'export' gets my vote.
Seems fine to me to add attributes to primary XML instance nodes and
leave those attributes unchanged when submitting a record. I think the
actual exporting/transforming to a particular format is something that the
client should not concern itself with. This should be up to the server
after receiving the submission.If we foresee a need for multiple formats in the future, using a generic
code:(or something else) namespace, as Matt suggested (so code:hxl=""),
would be sensible, since it seems unlikely we'd want to add several
different coding formats to the same form. We should define the namespace
and the different formats in the XForm spec, so the forms can be moved. Not
sure what namespace url we should use.Matt, the use case does not include adding codes to values (e.g. select
one values), right? That would be a different story...Cheers,
MartijnOn Monday, February 16, 2015 at 5:07:28 AM UTC-7, Christopher Robert wrote:
Hi Matt,
It's a good idea to sort out a method of including form- and
field-specific export options. With so many different ways of exporting
data from ODK systems, the method we've been using -- configure all export
options on the exporting computer -- is probably not idea. I could see a
different state of the world where the form itself has everything needed to
know how to export it."code" seems to me a little generic, though, and could refer to any
number of things. What if we started using an "export:" prefix followed by
different things for different export systems? So we might have
"export:stata:x", "export:googleearth:y", and "export:hxl:z".Ideally, we'd support export-related columns both on the survey sheet and
on the settings sheet (for field-specific and form-wide export options
respectively).Best,
Chris
On Mon Feb 16 2015 at 12:28:31 AM Matt Berg mlb...@gmail.com wrote:
Yaw,
Thanks that's very helpful.
Higher level problem is we want to create forms that can map to openmrs
concept ids. Another use case is tagging for things like hxl tags.We could use the name space for these but this makes forms non human
readable. Also, there may be cases there you just want to code a subset
of values in a form and do this retrospectively.Code to me seems like a term that would work well but am open to other
suggestions. I could also see allowing people to do things like code:hxl
code:iso9 (Two columns) if people wanted to use more then one coding
standard in form or just to provide a bit more detail what coding approach
is being used.We would like to standardize this approach as we will build tools around
this. Ie) data export that supports hxl.Note we will need to include codes on options tab too.
Thoughts everyone?
Matt
On Feb 15, 2015 11:27 PM, "Yaw Anokwa" yan...@nafundi.com wrote:Matt,
You can already add arbitrary columns to XLSForms and they will be
passed through to the XML, so there is nothing preventing you from
doing this already.
https://github.com/XLSForm/pyxform/commit/
ac2d3811822c533f9ac1b18315ef6cfabf816fe3If the goal is to get this new column as something that's standard in
all forms, then I think there needs to be a longer discussion around
what high level problem you are trying to solve and why you think this
solution is generic and ideal.Yaw
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.On Sun, Feb 15, 2015 at 1:18 PM, Matt Berg mlb...@gmail.com wrote:
We are exploring the idea of adding a "code" column to XLS Forms.
The idea is to be able to code medical concept ids or things like HXL
tags
into forms.First, I just wanted to see if the community had an issue with this
approach.Ie) should we use a new column or should we just use a label
instead. ie)
label:codeSecond, should we use code or another word like concept?
Thanks,
Matt
--
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.--
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.--
Revolutionizing data collection since 2012.Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/--
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
Yes, we need to clarify that.
If we're leaving the transforming/exporting (to HXL) to the server (i.e.
Aggregate, Ona etc), then the best place would be in the primary instance
of the XForm.
If the transforming (to HXL) happens on the client (i.e. Enketo or ODK
Collect) then adding the attributes to seems to make the most sense.
This is not a feature that I would support as I don't think it belongs on
the client.
Yes, true about the namespace URI being the only one that matters.
I am unclear where these new attributes would live....
They could be on the s or within the submission instance XML
(declared within the main ).
If they are within the then you could use XLSTs to transform
things (I think this is what Martijn is envisioning?)If they are within the then it is up to the hosting system to
interpret these attributes and handle them as it sees fit.Note that the namespace alias ('code' or 'export') is arbitrary. The
namespace URI is what should be compared when coding.'export' gets my vote.
On Tue, Feb 17, 2015 at 8:23 AM, Martijn van de Rijdt martijn@enketo.org wrote:
Seems fine to me to add attributes to primary XML instance nodes and
leave those attributes unchanged when submitting a record. I think the
actual exporting/transforming to a particular format is something that the
client should not concern itself with. This should be up to the server
after receiving the submission.If we foresee a need for multiple formats in the future, using a generic
code:(or something else) namespace, as Matt suggested (so code:hxl=""),
would be sensible, since it seems unlikely we'd want to add several
different coding formats to the same form. We should define the namespace
and the different formats in the XForm spec, so the forms can be moved. Not
sure what namespace url we should use.Matt, the use case does not include adding codes to values (e.g. select
one values), right? That would be a different story...Cheers,
MartijnOn Monday, February 16, 2015 at 5:07:28 AM UTC-7, Christopher Robert wrote:
Hi Matt,
It's a good idea to sort out a method of including form- and
field-specific export options. With so many different ways of exporting
data from ODK systems, the method we've been using -- configure all export
options on the exporting computer -- is probably not idea. I could see a
different state of the world where the form itself has everything needed to
know how to export it."code" seems to me a little generic, though, and could refer to any
number of things. What if we started using an "export:" prefix followed by
different things for different export systems? So we might have
"export:stata:x", "export:googleearth:y", and "export:hxl:z".Ideally, we'd support export-related columns both on the survey sheet
and on the settings sheet (for field-specific and form-wide export options
respectively).Best,
Chris
On Mon Feb 16 2015 at 12:28:31 AM Matt Berg mlb...@gmail.com wrote:
Yaw,
Thanks that's very helpful.
Higher level problem is we want to create forms that can map to openmrs
concept ids. Another use case is tagging for things like hxl tags.We could use the name space for these but this makes forms non human
readable. Also, there may be cases there you just want to code a subset
of values in a form and do this retrospectively.Code to me seems like a term that would work well but am open to other
suggestions. I could also see allowing people to do things like code:hxl
code:iso9 (Two columns) if people wanted to use more then one coding
standard in form or just to provide a bit more detail what coding approach
is being used.We would like to standardize this approach as we will build tools
around this. Ie) data export that supports hxl.Note we will need to include codes on options tab too.
Thoughts everyone?
Matt
On Feb 15, 2015 11:27 PM, "Yaw Anokwa" yan...@nafundi.com wrote:Matt,
You can already add arbitrary columns to XLSForms and they will be
passed through to the XML, so there is nothing preventing you from
doing this already.
https://github.com/XLSForm/pyxform/commit/
ac2d3811822c533f9ac1b18315ef6cfabf816fe3If the goal is to get this new column as something that's standard in
all forms, then I think there needs to be a longer discussion around
what high level problem you are trying to solve and why you think this
solution is generic and ideal.Yaw
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.On Sun, Feb 15, 2015 at 1:18 PM, Matt Berg mlb...@gmail.com wrote:
We are exploring the idea of adding a "code" column to XLS Forms.
The idea is to be able to code medical concept ids or things like
HXL tags
into forms.First, I just wanted to see if the community had an issue with this
approach.Ie) should we use a new column or should we just use a label
instead. ie)
label:codeSecond, should we use code or another word like concept?
Thanks,
Matt
--
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.--
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.--
Revolutionizing data collection since 2012.Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/--
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 a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/hESE9Diqcq0/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Revolutionizing data collection since 2012.
Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/
w.r.t. (1) -- this depends upon whether the server has access to the form
definition or not. If the server has the form definition, the presence of
the information in the submission XML is not as important. Having it in the
submission does, however, facilitate XLST manipulations.
On the other hand, having the attributes in the s keeps the byte
count of the filled-in form XML low -- that XML would not contain any of
these (boilerplate) transformation attributes that do not change from one
filled-in form to the next (or are determined by the specific version of
the form definition used when filling out the submission).
Mitch
Yes, we need to clarify that.
If we're leaving the transforming/exporting (to HXL) to the server
(i.e. Aggregate, Ona etc), then the best place would be in the primary
instance of the XForm.If the transforming (to HXL) happens on the client (i.e. Enketo or ODK
Collect) then adding the attributes to seems to make the most sense.
This is not a feature that I would support as I don't think it belongs on
the client.Yes, true about the namespace URI being the only one that matters.
On Tue, Feb 17, 2015 at 12:19 PM, Mitch Sundt mitchellsundt@gmail.com wrote:
I am unclear where these new attributes would live....
They could be on the s or within the submission instance XML
(declared within the main ).
If they are within the then you could use XLSTs to transform
things (I think this is what Martijn is envisioning?)If they are within the then it is up to the hosting system to
interpret these attributes and handle them as it sees fit.Note that the namespace alias ('code' or 'export') is arbitrary. The
namespace URI is what should be compared when coding.'export' gets my vote.
On Tue, Feb 17, 2015 at 8:23 AM, Martijn van de Rijdt <martijn@enketo.org wrote:
Seems fine to me to add attributes to primary XML instance nodes and
leave those attributes unchanged when submitting a record. I think the
actual exporting/transforming to a particular format is something that the
client should not concern itself with. This should be up to the server
after receiving the submission.If we foresee a need for multiple formats in the future, using a generic
code:(or something else) namespace, as Matt suggested (so code:hxl=""),
would be sensible, since it seems unlikely we'd want to add several
different coding formats to the same form. We should define the namespace
and the different formats in the XForm spec, so the forms can be moved. Not
sure what namespace url we should use.Matt, the use case does not include adding codes to values (e.g. select
one values), right? That would be a different story...Cheers,
MartijnOn Monday, February 16, 2015 at 5:07:28 AM UTC-7, Christopher Robert wrote:
Hi Matt,
It's a good idea to sort out a method of including form- and
field-specific export options. With so many different ways of exporting
data from ODK systems, the method we've been using -- configure all export
options on the exporting computer -- is probably not idea. I could see a
different state of the world where the form itself has everything needed to
know how to export it."code" seems to me a little generic, though, and could refer to any
number of things. What if we started using an "export:" prefix followed by
different things for different export systems? So we might have
"export:stata:x", "export:googleearth:y", and "export:hxl:z".Ideally, we'd support export-related columns both on the survey sheet
and on the settings sheet (for field-specific and form-wide export options
respectively).Best,
Chris
On Mon Feb 16 2015 at 12:28:31 AM Matt Berg mlb...@gmail.com wrote:
Yaw,
Thanks that's very helpful.
Higher level problem is we want to create forms that can map to
openmrs concept ids. Another use case is tagging for things like hxl
tags.We could use the name space for these but this makes forms non human
readable. Also, there may be cases there you just want to code a subset
of values in a form and do this retrospectively.Code to me seems like a term that would work well but am open to other
suggestions. I could also see allowing people to do things like code:hxl
code:iso9 (Two columns) if people wanted to use more then one coding
standard in form or just to provide a bit more detail what coding approach
is being used.We would like to standardize this approach as we will build tools
around this. Ie) data export that supports hxl.Note we will need to include codes on options tab too.
Thoughts everyone?
Matt
On Feb 15, 2015 11:27 PM, "Yaw Anokwa" yan...@nafundi.com wrote:Matt,
You can already add arbitrary columns to XLSForms and they will be
passed through to the XML, so there is nothing preventing you from
doing this already.
https://github.com/XLSForm/pyxform/commit/
ac2d3811822c533f9ac1b18315ef6cfabf816fe3If the goal is to get this new column as something that's standard in
all forms, then I think there needs to be a longer discussion around
what high level problem you are trying to solve and why you think this
solution is generic and ideal.Yaw
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.On Sun, Feb 15, 2015 at 1:18 PM, Matt Berg mlb...@gmail.com wrote:
We are exploring the idea of adding a "code" column to XLS Forms.
The idea is to be able to code medical concept ids or things like
HXL tags
into forms.First, I just wanted to see if the community had an issue with this
approach.Ie) should we use a new column or should we just use a label
instead. ie)
label:codeSecond, should we use code or another word like concept?
Thanks,
Matt
--
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.--
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.--
Revolutionizing data collection since 2012.Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/--
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 a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/hESE9Diqcq0/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.--
Revolutionizing data collection since 2012.Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/--
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
Yes, valid points. If #1 is what we're after, my vote goes for adding them
to the XML record but I'd have no objection to adding them to the s.
In my opinion, it seem more logical to tag the fields in the record instead
of requiring the additional processing to extract them from binds on the
server side.
For #1 'tag' is another option as the column name in XLSForm (and namespace
alias in XForm although as Mitch explained, it doesn't matter). I like
'tag' (or 'code') because I think the feature could perhaps also be used to
directly store any submitted data in HXL format in some custom server (no
'export'). It's a less opinionated name and describes better what it does
from the form format's perspective.
Revolutionizing data collection since 2012.
Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/
Bit lost on how to do this technically but agree not sure export is ideal
as this is also meant to allow us to specify how we store things internally
so I think something like code, tag or even map works better.
Keen to decide on an approach though as this is something we need to
implement for a few projects soon.
Thanks,
Matt
Yes, valid points. If #1 is what we're after, my vote goes for adding them
to the XML record but I'd have no objection to adding them to the s.
In my opinion, it seem more logical to tag the fields in the record instead
of requiring the additional processing to extract them from binds on the
server side.For #1 'tag' is another option as the column name in XLSForm (and
namespace alias in XForm although as Mitch explained, it doesn't matter). I
like 'tag' (or 'code') because I think the feature could perhaps also be
used to directly store any submitted data in HXL format in some custom
server (no 'export'). It's a less opinionated name and describes better
what it does from the form format's perspective.On Tuesday, February 17, 2015 at 2:19:21 PM UTC-7, Mitch wrote:
w.r.t. (1) -- this depends upon whether the server has access to the form
definition or not. If the server has the form definition, the presence of
the information in the submission XML is not as important. Having it in the
submission does, however, facilitate XLST manipulations.On the other hand, having the attributes in the s keeps the byte
count of the filled-in form XML low -- that XML would not contain any of
these (boilerplate) transformation attributes that do not change from one
filled-in form to the next (or are determined by the specific version of
the form definition used when filling out the submission).Mitch
On Tue, Feb 17, 2015 at 12:07 PM, Martijn van de Rijdt <mar...@enketo.org wrote:
Yes, we need to clarify that.
If we're leaving the transforming/exporting (to HXL) to the server
(i.e. Aggregate, Ona etc), then the best place would be in the primary
instance of the XForm.If the transforming (to HXL) happens on the client (i.e. Enketo or
ODK Collect) then adding the attributes to seems to make the most
sense. This is not a feature that I would support as I don't think it
belongs on the client.Yes, true about the namespace URI being the only one that matters.
On Tue, Feb 17, 2015 at 12:19 PM, Mitch Sundt mitche...@gmail.com wrote:
I am unclear where these new attributes would live....
They could be on the s or within the submission instance XML
(declared within the main ).
If they are within the then you could use XLSTs to
transform things (I think this is what Martijn is envisioning?)If they are within the then it is up to the hosting system to
interpret these attributes and handle them as it sees fit.Note that the namespace alias ('code' or 'export') is arbitrary. The
namespace URI is what should be compared when coding.'export' gets my vote.
On Tue, Feb 17, 2015 at 8:23 AM, Martijn van de Rijdt < mar...@enketo.org> wrote:
Seems fine to me to add attributes to primary XML instance nodes
and leave those attributes unchanged when submitting a record. I think the
actual exporting/transforming to a particular format is something that the
client should not concern itself with. This should be up to the server
after receiving the submission.If we foresee a need for multiple formats in the future, using a
genericcode:(or something else) namespace, as Matt suggested (so
code:hxl=""), would be sensible, since it seems unlikely we'd want to add
several different coding formats to the same form. We should define the
namespace and the different formats in the XForm spec, so the forms can be
moved. Not sure what namespace url we should use.Matt, the use case does not include adding codes to values (e.g.
select one values), right? That would be a different story...Cheers,
MartijnOn Monday, February 16, 2015 at 5:07:28 AM UTC-7, Christopher Robert wrote:
Hi Matt,
It's a good idea to sort out a method of including form- and
field-specific export options. With so many different ways of exporting
data from ODK systems, the method we've been using -- configure all export
options on the exporting computer -- is probably not idea. I could see a
different state of the world where the form itself has everything needed to
know how to export it."code" seems to me a little generic, though, and could refer to any
number of things. What if we started using an "export:" prefix followed by
different things for different export systems? So we might have
"export:stata:x", "export:googleearth:y", and "export:hxl:z".Ideally, we'd support export-related columns both on the survey sheet
and on the settings sheet (for field-specific and form-wide export options
respectively).Best,
Chris
On Mon Feb 16 2015 at 12:28:31 AM Matt Berg mlb...@gmail.com wrote:
Yaw,
Thanks that's very helpful.
Higher level problem is we want to create forms that can map to
openmrs concept ids. Another use case is tagging for things like hxl
tags.We could use the name space for these but this makes forms non human
readable. Also, there may be cases there you just want to code a subset
of values in a form and do this retrospectively.Code to me seems like a term that would work well but am open to
other suggestions. I could also see allowing people to do things like
code:hxl code:iso9 (Two columns) if people wanted to use more then one
coding standard in form or just to provide a bit more detail what coding
approach is being used.We would like to standardize this approach as we will build tools
around this. Ie) data export that supports hxl.Note we will need to include codes on options tab too.
Thoughts everyone?
Matt
On Feb 15, 2015 11:27 PM, "Yaw Anokwa" yan...@nafundi.com wrote:Matt,
You can already add arbitrary columns to XLSForms and they will be
passed through to the XML, so there is nothing preventing you from
doing this already.
https://github.com/XLSForm/pyxform/commit/ac2d3811822c533f9a
c1b18315ef6cfabf816fe3If the goal is to get this new column as something that's standard
in
all forms, then I think there needs to be a longer discussion around
what high level problem you are trying to solve and why you think
this
solution is generic and ideal.Yaw
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.On Sun, Feb 15, 2015 at 1:18 PM, Matt Berg mlb...@gmail.com wrote:
We are exploring the idea of adding a "code" column to XLS Forms.
The idea is to be able to code medical concept ids or things like
HXL tags
into forms.First, I just wanted to see if the community had an issue with
this
approach.Ie) should we use a new column or should we just use a label
instead. ie)
label:codeSecond, should we use code or another word like concept?
Thanks,
Matt
--
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+unsubsc
ribe@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.--
Revolutionizing data collection since 2012.Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter
https://twitter.com/enketo | Blog http://blog.enketo.org/--
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
mitche...@gmail.com--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/
topic/opendatakit-developers/hESE9Diqcq0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.--
Revolutionizing data collection since 2012.Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/--
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
mitche...@gmail.com--
Revolutionizing data collection since 2012.Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/--
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.
Matt,
Just simple tagging of questions with a code is what you're after, right?
No tagging of specific select_one or select_multiple values, right?
Cheers,
Martijn
Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/
No we need the ability to code options too
Matt,
Just simple tagging of questions with a code is what you're after, right?
No tagging of specific select_one or select_multiple values, right?Cheers,
MartijnOn Sunday, February 22, 2015 at 6:41:17 AM UTC-7, Matt Berg wrote:
Bit lost on how to do this technically but agree not sure export is ideal
as this is also meant to allow us to specify how we store things internally
so I think something like code, tag or even map works better.Keen to decide on an approach though as this is something we need to
implement for a few projects soon.Thanks,
Matt
On Feb 19, 2015 7:25 PM, "Martijn van de Rijdt" mar...@enketo.org wrote:Yes, valid points. If #1 is what we're after, my vote goes for adding
them to the XML record but I'd have no objection to adding them to the
s. In my opinion, it seem more logical to tag the fields in the
record instead of requiring the additional processing to extract them from
binds on the server side.For #1 'tag' is another option as the column name in XLSForm (and
namespace alias in XForm although as Mitch explained, it doesn't matter). I
like 'tag' (or 'code') because I think the feature could perhaps also be
used to directly store any submitted data in HXL format in some custom
server (no 'export'). It's a less opinionated name and describes better
what it does from the form format's perspective.On Tuesday, February 17, 2015 at 2:19:21 PM UTC-7, Mitch wrote:
w.r.t. (1) -- this depends upon whether the server has access to the
form definition or not. If the server has the form definition, the presence
of the information in the submission XML is not as important. Having it in
the submission does, however, facilitate XLST manipulations.On the other hand, having the attributes in the s keeps the byte
count of the filled-in form XML low -- that XML would not contain any of
these (boilerplate) transformation attributes that do not change from one
filled-in form to the next (or are determined by the specific version of
the form definition used when filling out the submission).Mitch
On Tue, Feb 17, 2015 at 12:07 PM, Martijn van de Rijdt < mar...@enketo.org> wrote:
Yes, we need to clarify that.
If we're leaving the transforming/exporting (to HXL) to the server
(i.e. Aggregate, Ona etc), then the best place would be in the primary
instance of the XForm.If the transforming (to HXL) happens on the client (i.e. Enketo or
ODK Collect) then adding the attributes to seems to make the most
sense. This is not a feature that I would support as I don't think it
belongs on the client.Yes, true about the namespace URI being the only one that matters.
On Tue, Feb 17, 2015 at 12:19 PM, Mitch Sundt mitche...@gmail.com wrote:
I am unclear where these new attributes would live....
They could be on the s or within the submission instance XML
(declared within the main ).
If they are within the then you could use XLSTs to
transform things (I think this is what Martijn is envisioning?)If they are within the then it is up to the hosting system
to interpret these attributes and handle them as it sees fit.Note that the namespace alias ('code' or 'export') is arbitrary. The
namespace URI is what should be compared when coding.'export' gets my vote.
On Tue, Feb 17, 2015 at 8:23 AM, Martijn van de Rijdt < mar...@enketo.org> wrote:
Seems fine to me to add attributes to primary XML instance nodes
and leave those attributes unchanged when submitting a record. I think the
actual exporting/transforming to a particular format is something that the
client should not concern itself with. This should be up to the server
after receiving the submission.If we foresee a need for multiple formats in the future, using a
genericcode:(or something else) namespace, as Matt suggested (so
code:hxl=""), would be sensible, since it seems unlikely we'd want to add
several different coding formats to the same form. We should define the
namespace and the different formats in the XForm spec, so the forms can be
moved. Not sure what namespace url we should use.Matt, the use case does not include adding codes to values (e.g.
select one values), right? That would be a different story...Cheers,
MartijnOn Monday, February 16, 2015 at 5:07:28 AM UTC-7, Christopher Robert wrote:
Hi Matt,
It's a good idea to sort out a method of including form- and
field-specific export options. With so many different ways of exporting
data from ODK systems, the method we've been using -- configure all export
options on the exporting computer -- is probably not idea. I could see a
different state of the world where the form itself has everything needed to
know how to export it."code" seems to me a little generic, though, and could refer to any
number of things. What if we started using an "export:" prefix followed by
different things for different export systems? So we might have
"export:stata:x", "export:googleearth:y", and "export:hxl:z".Ideally, we'd support export-related columns both on the survey
sheet and on the settings sheet (for field-specific and form-wide export
options respectively).Best,
Chris
On Mon Feb 16 2015 at 12:28:31 AM Matt Berg mlb...@gmail.com wrote:
Yaw,
Thanks that's very helpful.
Higher level problem is we want to create forms that can map to
openmrs concept ids. Another use case is tagging for things like hxl
tags.We could use the name space for these but this makes forms non
human readable. Also, there may be cases there you just want to code a
subset of values in a form and do this retrospectively.Code to me seems like a term that would work well but am open to
other suggestions. I could also see allowing people to do things like
code:hxl code:iso9 (Two columns) if people wanted to use more then one
coding standard in form or just to provide a bit more detail what coding
approach is being used.We would like to standardize this approach as we will build tools
around this. Ie) data export that supports hxl.Note we will need to include codes on options tab too.
Thoughts everyone?
Matt
On Feb 15, 2015 11:27 PM, "Yaw Anokwa" yan...@nafundi.com wrote:Matt,
You can already add arbitrary columns to XLSForms and they will be
passed through to the XML, so there is nothing preventing you from
doing this already.
https://github.com/XLSForm/pyxform/commit/ac2d3811822c533f9a
c1b18315ef6cfabf816fe3If the goal is to get this new column as something that's
standard in
all forms, then I think there needs to be a longer discussion
around
what high level problem you are trying to solve and why you think
this
solution is generic and ideal.Yaw
Need ODK services? http://nafundi.com provides form design,
server
setup, professional support, and software development for ODK.On Sun, Feb 15, 2015 at 1:18 PM, Matt Berg mlb...@gmail.com wrote:
We are exploring the idea of adding a "code" column to XLS
Forms.The idea is to be able to code medical concept ids or things
like HXL tags
into forms.First, I just wanted to see if the community had an issue with
this
approach.Ie) should we use a new column or should we just use a label
instead. ie)
label:codeSecond, should we use code or another word like concept?
Thanks,
Matt
--
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+unsubsc
ribe@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+unsubsc
ribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.--
Revolutionizing data collection since 2012.Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter
https://twitter.com/enketo | Blog http://blog.enketo.org/--
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
mitche...@gmail.com--
You received this message because you are subscribed to a topic in
the Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/to
pic/opendatakit-developers/hESE9Diqcq0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.--
Revolutionizing data collection since 2012.Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter
https://twitter.com/enketo | Blog http://blog.enketo.org/--
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
mitche...@gmail.com--
Revolutionizing data collection since 2012.Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/--
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.--
Revolutionizing data collection since 2012.Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/--
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.
Hmm. That changes everything. Unless somebody has an idea to add this to
the XForm format nicely, I'm wondering if a better approach would be to
keep this outside of the XForm format and data collection clients entirely.
Maybe instead only include this in the JSON XLSForm output, and process
traditional XML records when they are submitted?
Enketo https://enketo.org/ | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/enketo | Twitter https://twitter.com/enketo
| Blog http://blog.enketo.org/