Best way to extend XLSForm?

[yanokwa]

Hi all,

We've added true auto save to Collect. This feature was needed because
we have a client who needs to save as incomplete at a particular point
in the form before launching an external widget.

The XML looks like this:

Before we push this code to trunk, we want to add support for it in
XLSForm. The obvious way to do this is to add a new column, but I
don't think it's sustainable in the long run for every attribute we
might want to add.

I wanted to bring this discussion to the community to solicit ideas.
Is the status quo of adding a named column what we want? Or do we want
a more generic solution?

For example, any column with body::x as a header would insert x as an
attribute in the body XML? And bind::y would insert y as in attribute
in the bind XML.

Good idea? Terrible idea?

Yaw

···

-- Need ODK services? http://nafundi.com provides form design, server setup, professional support, and software development for ODK.

[Matt_Berg]

Can you elaborate with an xlsform example of how this would work.

Instead of adding new columns we cooked add a properties column and have
these be comma delimited or something like that.

···

On Jul 16, 2014 2:56 PM, "Yaw Anokwa" wrote:

Hi all,

We've added true auto save to Collect. This feature was needed because
we have a client who needs to save as incomplete at a particular point
in the form before launching an external widget.

The XML looks like this:

Before we push this code to trunk, we want to add support for it in
XLSForm. The obvious way to do this is to add a new column, but I
don't think it's sustainable in the long run for every attribute we
might want to add.

I wanted to bring this discussion to the community to solicit ideas.
Is the status quo of adding a named column what we want? Or do we want
a more generic solution?

For example, any column with body::x as a header would insert x as an
attribute in the body XML? And bind::y would insert y as in attribute
in the bind XML.

Good idea? Terrible idea?

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

--
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.

[yanokwa]

I still want there to be new columns, but we don't have to hard code
them into pyxform.

Attributes can appear in the instance, bind, and in the body, so my
proposal is to have three new column headers that a user can add if
they want a new attribute. So, instance::$x, bind::$x, and body::$x

So for the autocomplete example, that appears in the bind, so you'd
add a column with bind::saveIncomplete. And in the row, you'd put
true().

Then pyxform would know to generate this:

You could also then add another column with bind::myAttribute, and
then the XML would look like:

Again, we are adding new columns to the XLS, but we don't have to also
add them to the pyxform code.

I think having one properties column where everything is separated by
commas seems more fragile and harder to debug.

···

On Wed, Jul 16, 2014 at 10:41 AM, Matt Berg wrote: > Can you elaborate with an xlsform example of how this would work. > > Instead of adding new columns we cooked add a properties column and have > these be comma delimited or something like that. > > On Jul 16, 2014 2:56 PM, "Yaw Anokwa" wrote: >> >> Hi all, >> >> We've added true auto save to Collect. This feature was needed because >> we have a client who needs to save as incomplete at a particular point >> in the form before launching an external widget. >> >> The XML looks like this: >> >> >> Before we push this code to trunk, we want to add support for it in >> XLSForm. The obvious way to do this is to add a new column, but I >> don't think it's sustainable in the long run for every attribute we >> might want to add. >> >> I wanted to bring this discussion to the community to solicit ideas. >> Is the status quo of adding a named column what we want? Or do we want >> a more generic solution? >> >> For example, any column with body::x as a header would insert x as an >> attribute in the body XML? And bind::y would insert y as in attribute >> in the bind XML. >> >> Good idea? Terrible idea? >> >> Yaw >> -- >> Need ODK services? http://nafundi.com provides form design, server >> setup, professional support, and software development for ODK. >> >> -- >> 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.

[crobert]

One argument against new-columns-for-new-attributes is that it makes it
hard to have a single "template" that people can use for multiple surveys.
At SurveyCTO, we early on established the norm that we'd provide form
templates and users would fill them in -- without having to add columns.
And then we made sure that every one of our samples used the same template.
The reason was this: everybody wants to copy and paste between surveys
(more or less all the time) and this leads to enormous difficulties when
the set and order of columns isn't shared between the different surveys. We
estimate that a large proportion of users' debugging time can easily go
into debugging copy-paste problems that are themselves the result of
differing column sets or orders. And that's just a terrible shame. Thus,
the attempt to stamp out those errors with a single template.

Now, granted, comma-delimited lists of name-value pairs is maybe hard for
users to construct and debug. What if we had a series of pre-set property
columns like property-name1, property-value1, property-name2, and so on?
Actually, pyxform would only need to support property-name* and
property-value*, and it would be up to crazy people like us to build
templates with a pre-fab set of them for users to fill in. But actually, it
would also be wonderful if people could easily copy and paste between ODK,
formhub, Ona, Enketo, and SurveyCTO surveys... so if others wanted to jump
on the "master template" idea, we could settle on a default or example
template that has the same set and order of columns across our different
systems. I think that everybody would benefit.

Obviously, the XML format is naturally better at supporting ad-hoc
attributes. I'm just trying to imagine what works well in the spreadsheet
format.

Best,

Chris

···

On Wed, Jul 16, 2014 at 7:16 PM, Yaw Anokwa wrote:

I still want there to be new columns, but we don't have to hard code
them into pyxform.

Attributes can appear in the instance, bind, and in the body, so my
proposal is to have three new column headers that a user can add if
they want a new attribute. So, instance::$x, bind::$x, and body::$x

So for the autocomplete example, that appears in the bind, so you'd
add a column with bind::saveIncomplete. And in the row, you'd put
true().

Then pyxform would know to generate this:

You could also then add another column with bind::myAttribute, and
then the XML would look like:

Again, we are adding new columns to the XLS, but we don't have to also
add them to the pyxform code.

I think having one properties column where everything is separated by
commas seems more fragile and harder to debug.

On Wed, Jul 16, 2014 at 10:41 AM, Matt Berg mlberg@gmail.com wrote:

Can you elaborate with an xlsform example of how this would work.

Instead of adding new columns we cooked add a properties column and have
these be comma delimited or something like that.

On Jul 16, 2014 2:56 PM, "Yaw Anokwa" yanokwa@nafundi.com wrote:

Hi all,

We've added true auto save to Collect. This feature was needed because
we have a client who needs to save as incomplete at a particular point
in the form before launching an external widget.

The XML looks like this:

Before we push this code to trunk, we want to add support for it in
XLSForm. The obvious way to do this is to add a new column, but I
don't think it's sustainable in the long run for every attribute we
might want to add.

I wanted to bring this discussion to the community to solicit ideas.
Is the status quo of adding a named column what we want? Or do we want
a more generic solution?

For example, any column with body::x as a header would insert x as an
attribute in the body XML? And bind::y would insert y as in attribute
in the bind XML.

Good idea? Terrible idea?

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

--
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.

[Mitch_S]

Chris raises an interesting issue.

I think, however, that we want to be able to easily add columns to XLSForm,
and Yaw's suggestion is a good one.

We need to be able to add attributes to at least the bind element, and I
would argue we should allow them on the input element as well.

The odk:length, constraintMsg and requiredMsg are all on the bind, and
don't make sense to attach to the input element via the appearance. They
belong on the bind.

For Enketo and other tools that are trying to render the forms more freely
and leverage the power of HTML and CSS, I would argue that the appearance
attribute is too constraining. We should allow new attributes to be added
to the input element for easier extension and development of these tools. I
could imagine wanting to define body::style on them, for example.

And then there are things like the accuracy threshold for geopoints. These
aren't constraints on the value, since a location can always be accepted
early by the user, so they should be tied to the input element, but they
don't affect appearance; they affect behavior. So it is awkward to stuff
them in the appearance attribute. Other examples might be resolution
settings for image capture and video capture, or specifications of image,
audio, or video formats. But,given the external intent launching mechanism
that exists within the appearance attribute, and its support of argument
lists, perhaps these behavioral settings, that are currently separate
attributes, should be moved into the argument list of the appearance
(e.g., appearance="maps(1.5)" instead of appearance="maps"
accuracyThreshold="1.5"). The downside of placing everything in the
appearance is that you lose the readability of the XML -- you need to refer
to our spec documents to know what 1.5 does, whereas having a separate
attribute provides some self-documentation.

I don't think it is reasonable to freeze the spec and allow no new
attributes. Several years ago, I modified the original JR library to allow
new attributes specifically because it didn't allow attributes like
odk:length on the bind.

To Chris' point, however, we might need a .NET app or other tool that will
unify the order and set of columns between two or more XLS forms, so that
cutting-and-pasting will then work. And we should be clearer when we update
our example XLS forms so that we clearly communicate the changes across
those versions. It would also be useful if we could collectively adopt an
agreed-upon order of columns for all of our examples, and make them all
consistent, just to eliminate this point of confusion.

Mitch

···

On Wed, Jul 16, 2014 at 6:02 PM, Christopher Robert wrote:

One argument against new-columns-for-new-attributes is that it makes it
hard to have a single "template" that people can use for multiple surveys.
At SurveyCTO, we early on established the norm that we'd provide form
templates and users would fill them in -- without having to add columns.
And then we made sure that every one of our samples used the same template.
The reason was this: everybody wants to copy and paste between surveys
(more or less all the time) and this leads to enormous difficulties when
the set and order of columns isn't shared between the different surveys. We
estimate that a large proportion of users' debugging time can easily go
into debugging copy-paste problems that are themselves the result of
differing column sets or orders. And that's just a terrible shame. Thus,
the attempt to stamp out those errors with a single template.

Now, granted, comma-delimited lists of name-value pairs is maybe hard for
users to construct and debug. What if we had a series of pre-set property
columns like property-name1, property-value1, property-name2, and so on?
Actually, pyxform would only need to support property-name* and
property-value*, and it would be up to crazy people like us to build
templates with a pre-fab set of them for users to fill in. But actually, it
would also be wonderful if people could easily copy and paste between ODK,
formhub, Ona, Enketo, and SurveyCTO surveys... so if others wanted to jump
on the "master template" idea, we could settle on a default or example
template that has the same set and order of columns across our different
systems. I think that everybody would benefit.

Obviously, the XML format is naturally better at supporting ad-hoc
attributes. I'm just trying to imagine what works well in the spreadsheet
format.

Best,

Chris

On Wed, Jul 16, 2014 at 7:16 PM, Yaw Anokwa yanokwa@nafundi.com wrote:

I still want there to be new columns, but we don't have to hard code
them into pyxform.

Attributes can appear in the instance, bind, and in the body, so my
proposal is to have three new column headers that a user can add if
they want a new attribute. So, instance::$x, bind::$x, and body::$x

So for the autocomplete example, that appears in the bind, so you'd
add a column with bind::saveIncomplete. And in the row, you'd put
true().

Then pyxform would know to generate this:

You could also then add another column with bind::myAttribute, and
then the XML would look like:

Again, we are adding new columns to the XLS, but we don't have to also
add them to the pyxform code.

I think having one properties column where everything is separated by
commas seems more fragile and harder to debug.

On Wed, Jul 16, 2014 at 10:41 AM, Matt Berg mlberg@gmail.com wrote:

Can you elaborate with an xlsform example of how this would work.

Instead of adding new columns we cooked add a properties column and have
these be comma delimited or something like that.

On Jul 16, 2014 2:56 PM, "Yaw Anokwa" yanokwa@nafundi.com wrote:

Hi all,

We've added true auto save to Collect. This feature was needed because
we have a client who needs to save as incomplete at a particular point
in the form before launching an external widget.

The XML looks like this:

Before we push this code to trunk, we want to add support for it in
XLSForm. The obvious way to do this is to add a new column, but I
don't think it's sustainable in the long run for every attribute we
might want to add.

I wanted to bring this discussion to the community to solicit ideas.
Is the status quo of adding a named column what we want? Or do we want
a more generic solution?

For example, any column with body::x as a header would insert x as an
attribute in the body XML? And bind::y would insert y as in attribute
in the bind XML.

Good idea? Terrible idea?

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

--
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.

--
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

[yanokwa]

Agreed that we can at least standardize the ordering. I don't think it
should be strict, but a warning seems reasonable. Ditto with
attributes that aren't supported by all tools.

Martjin? Matt? You guys have been quiet. Thoughts on how we support
attributes going forward?

Yaw

···

-- Need ODK services? http://nafundi.com provides form design, server setup, professional support, and software development for ODK.

On Fri, Jul 18, 2014 at 7:21 PM, Mitch Sundt mitchellsundt@gmail.com wrote:

Chris raises an interesting issue.

I think, however, that we want to be able to easily add columns to XLSForm,
and Yaw's suggestion is a good one.

We need to be able to add attributes to at least the bind element, and I
would argue we should allow them on the input element as well.

The odk:length, constraintMsg and requiredMsg are all on the bind, and don't
make sense to attach to the input element via the appearance. They belong on
the bind.

For Enketo and other tools that are trying to render the forms more freely
and leverage the power of HTML and CSS, I would argue that the appearance
attribute is too constraining. We should allow new attributes to be added to
the input element for easier extension and development of these tools. I
could imagine wanting to define body::style on them, for example.

And then there are things like the accuracy threshold for geopoints. These
aren't constraints on the value, since a location can always be accepted
early by the user, so they should be tied to the input element, but they
don't affect appearance; they affect behavior. So it is awkward to stuff
them in the appearance attribute. Other examples might be resolution
settings for image capture and video capture, or specifications of image,
audio, or video formats. But,given the external intent launching mechanism
that exists within the appearance attribute, and its support of argument
lists, perhaps these behavioral settings, that are currently separate
attributes, should be moved into the argument list of the appearance (e.g.,
appearance="maps(1.5)" instead of appearance="maps"
accuracyThreshold="1.5"). The downside of placing everything in the
appearance is that you lose the readability of the XML -- you need to refer
to our spec documents to know what 1.5 does, whereas having a separate
attribute provides some self-documentation.

I don't think it is reasonable to freeze the spec and allow no new
attributes. Several years ago, I modified the original JR library to allow
new attributes specifically because it didn't allow attributes like
odk:length on the bind.

To Chris' point, however, we might need a .NET app or other tool that will
unify the order and set of columns between two or more XLS forms, so that
cutting-and-pasting will then work. And we should be clearer when we update
our example XLS forms so that we clearly communicate the changes across
those versions. It would also be useful if we could collectively adopt an
agreed-upon order of columns for all of our examples, and make them all
consistent, just to eliminate this point of confusion.

Mitch

On Wed, Jul 16, 2014 at 6:02 PM, Christopher Robert crobert@surveycto.com wrote:

One argument against new-columns-for-new-attributes is that it makes it
hard to have a single "template" that people can use for multiple surveys.
At SurveyCTO, we early on established the norm that we'd provide form
templates and users would fill them in -- without having to add columns. And
then we made sure that every one of our samples used the same template. The
reason was this: everybody wants to copy and paste between surveys (more or
less all the time) and this leads to enormous difficulties when the set and
order of columns isn't shared between the different surveys. We estimate
that a large proportion of users' debugging time can easily go into
debugging copy-paste problems that are themselves the result of differing
column sets or orders. And that's just a terrible shame. Thus, the attempt
to stamp out those errors with a single template.

Now, granted, comma-delimited lists of name-value pairs is maybe hard for
users to construct and debug. What if we had a series of pre-set property
columns like property-name1, property-value1, property-name2, and so on?
Actually, pyxform would only need to support property-name* and
property-value*, and it would be up to crazy people like us to build
templates with a pre-fab set of them for users to fill in. But actually, it
would also be wonderful if people could easily copy and paste between ODK,
formhub, Ona, Enketo, and SurveyCTO surveys... so if others wanted to jump
on the "master template" idea, we could settle on a default or example
template that has the same set and order of columns across our different
systems. I think that everybody would benefit.

Obviously, the XML format is naturally better at supporting ad-hoc
attributes. I'm just trying to imagine what works well in the spreadsheet
format.

Best,

Chris

On Wed, Jul 16, 2014 at 7:16 PM, Yaw Anokwa yanokwa@nafundi.com wrote:

I still want there to be new columns, but we don't have to hard code
them into pyxform.

Attributes can appear in the instance, bind, and in the body, so my
proposal is to have three new column headers that a user can add if
they want a new attribute. So, instance::$x, bind::$x, and body::$x

So for the autocomplete example, that appears in the bind, so you'd
add a column with bind::saveIncomplete. And in the row, you'd put
true().

Then pyxform would know to generate this:

You could also then add another column with bind::myAttribute, and
then the XML would look like:

Again, we are adding new columns to the XLS, but we don't have to also
add them to the pyxform code.

I think having one properties column where everything is separated by
commas seems more fragile and harder to debug.

On Wed, Jul 16, 2014 at 10:41 AM, Matt Berg mlberg@gmail.com wrote:

Can you elaborate with an xlsform example of how this would work.

Instead of adding new columns we cooked add a properties column and
have
these be comma delimited or something like that.

On Jul 16, 2014 2:56 PM, "Yaw Anokwa" yanokwa@nafundi.com wrote:

Hi all,

We've added true auto save to Collect. This feature was needed because
we have a client who needs to save as incomplete at a particular point
in the form before launching an external widget.

The XML looks like this:

Before we push this code to trunk, we want to add support for it in
XLSForm. The obvious way to do this is to add a new column, but I
don't think it's sustainable in the long run for every attribute we
might want to add.

I wanted to bring this discussion to the community to solicit ideas.
Is the status quo of adding a named column what we want? Or do we want
a more generic solution?

For example, any column with body::x as a header would insert x as an
attribute in the body XML? And bind::y would insert y as in attribute
in the bind XML.

Good idea? Terrible idea?

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

--
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.

--
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.

[martijnr]

Hi,

Back from holiday. Thanks for sharing this.

Re. adding new binding attributes to XLSForm:

In my opinion, the support of bind:newattribute would be a very worthwhile
addition to XLSForm for the purpose of allowing developers to add
client-specific features without forking XLSForm (and to facilitate testing
new features during development while waiting for XLSForm support).
However, for a feature that is part of the ODK XForm and XLSForm spec (and
supported in the public ODK Collect), I think we should always add a
separate column without the bind:: prefix. It just keeps the XLSForm format
a lot more user-friendly and facilitates validation. (so XLSForm could
ignore and bind::newattribute column if newattribute has its own column in
the .xls file it's transforming).

Re. new attributes on input/select/select1/itemset elements:

Though the idea of using appearance parameters has a lot of appeal at first
glance, I'd like to keep appearances as simple strings without parameters
(functioning like a style class). Anything that requires parameter(s) such
as accuracyThreshold should get its own column in my opinion. For me the
issue with allowing parameters in appearances is that appearances should
ALWAYS be static for performance reasons and to keep form parsing sane.
Once you allow parameters it becomes too hard to explain why node
references and XPath functions are not allowed as appearance parameters but
are allowed in every other function in a form definition.

Adding support for body::newattribute to XLSForm (for development or for
client-specific features) runs into a minor difficulty of what to do with
select and select1 elements as the attribute may be better placed on an
child (e.g. a search attribute). Nevertheless, it may be useful
to add this support and just add the attribute to select, select1 and input
elements only.

Cheers,
Martijn

PS (not directly relevant to this general XLSForm extension discussion):

• In the case of accuracyThreshold I think it would make sense to move
  this to the settings column to make this a form-wide setting that could
  added to h:body in XForm.)
• I may be misunderstanding the autoSave feature (which would seem a
  great addition) but if not, I have strong reservations about implementing
  this by adding the autoSave instruction to a particular node (instead of to
  the whole form). I'll save those for a different thread if the feature is
  meant for the the public ODK Collect. I have the same reservation for any
  feature that is dependent on a form having one question per page and
  requires a user to traverse a form question by question.

···

On Saturday, July 19, 2014 6:20:45 AM UTC-6, Yaw Anokwa wrote: > > Agreed that we can at least standardize the ordering. I don't think it > should be strict, but a warning seems reasonable. Ditto with > attributes that aren't supported by all tools. > > Martjin? Matt? You guys have been quiet. Thoughts on how we support > attributes going forward? > > Yaw > -- > Need ODK services? http://nafundi.com provides form design, server > setup, professional support, and software development for ODK. > > On Fri, Jul 18, 2014 at 7:21 PM, Mitch Sundt <mitche...@gmail.com > wrote: > > Chris raises an interesting issue. > > > > I think, however, that we want to be able to easily add columns to > XLSForm, > > and Yaw's suggestion is a good one. > > > > We need to be able to add attributes to at least the bind element, and I > > would argue we should allow them on the input element as well. > > > > The odk:length, constraintMsg and requiredMsg are all on the bind, and > don't > > make sense to attach to the input element via the appearance. They > belong on > > the bind. > > > > For Enketo and other tools that are trying to render the forms more > freely > > and leverage the power of HTML and CSS, I would argue that the > appearance > > attribute is too constraining. We should allow new attributes to be > added to > > the input element for easier extension and development of these tools. I > > could imagine wanting to define body::style on them, for example. > > > > And then there are things like the accuracy threshold for geopoints. > These > > aren't constraints on the value, since a location can always be accepted > > early by the user, so they should be tied to the input element, but they > > don't affect appearance; they affect behavior. So it is awkward to stuff > > them in the appearance attribute. Other examples might be resolution > > settings for image capture and video capture, or specifications of > image, > > audio, or video formats. But,given the external intent launching > mechanism > > that exists within the appearance attribute, and its support of argument > > lists, perhaps these behavioral settings, that are currently separate > > attributes, should be moved into the argument list of the appearance > (e.g., > > appearance="maps(1.5)" instead of appearance="maps" > > accuracyThreshold="1.5"). The downside of placing everything in the > > appearance is that you lose the readability of the XML -- you need to > refer > > to our spec documents to know what 1.5 does, whereas having a separate > > attribute provides some self-documentation. > > > > I don't think it is reasonable to freeze the spec and allow no new > > attributes. Several years ago, I modified the original JR library to > allow > > new attributes specifically because it didn't allow attributes like > > odk:length on the bind. > > > > To Chris' point, however, we might need a .NET app or other tool that > will > > unify the order and set of columns between two or more XLS forms, so > that > > cutting-and-pasting will then work. And we should be clearer when we > update > > our example XLS forms so that we clearly communicate the changes across > > those versions. It would also be useful if we could collectively adopt > an > > agreed-upon order of columns for all of our examples, and make them all > > consistent, just to eliminate this point of confusion. > > > > Mitch > > > > > > > > On Wed, Jul 16, 2014 at 6:02 PM, Christopher Robert < cro...@surveycto.com > wrote: > >> > >> One argument against new-columns-for-new-attributes is that it makes it > >> hard to have a single "template" that people can use for multiple > surveys. > >> At SurveyCTO, we early on established the norm that we'd provide form > >> templates and users would fill them in -- without having to add > columns. And > >> then we made sure that every one of our samples used the same template. > The > >> reason was this: everybody wants to copy and paste between surveys > (more or > >> less all the time) and this leads to enormous difficulties when the set > and > >> order of columns isn't shared between the different surveys. We > estimate > >> that a large proportion of users' debugging time can easily go into > >> debugging copy-paste problems that are themselves the result of > differing > >> column sets or orders. And that's just a terrible shame. Thus, the > attempt > >> to stamp out those errors with a single template. > >> > >> Now, granted, comma-delimited lists of name-value pairs is maybe hard > for > >> users to construct and debug. What if we had a series of pre-set > property > >> columns like property-name1, property-value1, property-name2, and so > on? > >> Actually, pyxform would only need to support property-name* and > >> property-value*, and it would be up to crazy people like us to build > >> templates with a pre-fab set of them for users to fill in. But > actually, it > >> would also be wonderful if people could easily copy and paste between > ODK, > >> formhub, Ona, Enketo, and SurveyCTO surveys... so if others wanted to > jump > >> on the "master template" idea, we could settle on a default or example > >> template that has the same set and order of columns across our > different > >> systems. I think that everybody would benefit. > >> > >> Obviously, the XML format is naturally better at supporting ad-hoc > >> attributes. I'm just trying to imagine what works well in the > spreadsheet > >> format. > >> > >> Best, > >> > >> Chris > >> > >> > >> > >> > >> > >> On Wed, Jul 16, 2014 at 7:16 PM, Yaw Anokwa <yan...@nafundi.com > wrote: > >>> > >>> I still want there to be new columns, but we don't have to hard code > >>> them into pyxform. > >>> > >>> Attributes can appear in the instance, bind, and in the body, so my > >>> proposal is to have three new column headers that a user can add if > >>> they want a new attribute. So, instance::$x, bind::$x, and body::$x > >>> > >>> So for the autocomplete example, that appears in the bind, so you'd > >>> add a column with bind::saveIncomplete. And in the row, you'd put > >>> true(). > >>> > >>> Then pyxform would know to generate this: > >>> > >>> > >>> You could also then add another column with bind::myAttribute, and > >>> then the XML would look like: > >>> >>> myAttribute="whatever" /> > >>> > >>> Again, we are adding new columns to the XLS, but we don't have to also > >>> add them to the pyxform code. > >>> > >>> I think having one properties column where everything is separated by > >>> commas seems more fragile and harder to debug. > >>> > >>> On Wed, Jul 16, 2014 at 10:41 AM, Matt Berg <mlb...@gmail.com > wrote: > >>> > Can you elaborate with an xlsform example of how this would work. > >>> > > >>> > Instead of adding new columns we cooked add a properties column and > >>> > have > >>> > these be comma delimited or something like that. > >>> > > >>> > On Jul 16, 2014 2:56 PM, "Yaw Anokwa" <yan...@nafundi.com > wrote: > >>> >> > >>> >> Hi all, > >>> >> > >>> >> We've added true auto save to Collect. This feature was needed > because > >>> >> we have a client who needs to save as incomplete at a particular > point > >>> >> in the form before launching an external widget. > >>> >> > >>> >> The XML looks like this: > >>> >> /> > >>> >> > >>> >> Before we push this code to trunk, we want to add support for it in > >>> >> XLSForm. The obvious way to do this is to add a new column, but I > >>> >> don't think it's sustainable in the long run for every attribute we > >>> >> might want to add. > >>> >> > >>> >> I wanted to bring this discussion to the community to solicit > ideas. > >>> >> Is the status quo of adding a named column what we want? Or do we > want > >>> >> a more generic solution? > >>> >> > >>> >> For example, any column with body::x as a header would insert x as > an > >>> >> attribute in the body XML? And bind::y would insert y as in > attribute > >>> >> in the bind XML. > >>> >> > >>> >> Good idea? Terrible idea? > >>> >> > >>> >> Yaw > >>> >> -- > >>> >> Need ODK services? http://nafundi.com provides form design, server > >>> >> setup, professional support, and software development for ODK. > >>> >> > >>> >> -- > >>> >> 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. > >> > >> > >> -- > >> 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 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. >

[yanokwa]

Martijn,

Sounds like we have rough consensus on bind::newattribute. We'll start
hacking away on it and submit a patch for review. My guess is that
we'll add a whitelist of standard columns and warn (but passthrough)
on any non-standard columns. We can also probably warn on if the
ordering isn't whatever we agree on.

I'm not clear on the select/select1 issue. Can you provide an example?

autoSave needs to be question specific because saving takes a long
time and so you can't save on swipe. You want the form designer to
specify when the save occurs, no? Curious why this would be
problematic for you.

Agreed that appearance should be static. If we need parameters for
external widgets, then that seems like the bind::newattribute is the
mechanism we should use.

accuracyThreshold should be question specific. I don't feel very
strongly about it, but I can imagine situations where form specific is
not adequate.

Yaw

···

On Mon, Jul 21, 2014 at 8:23 AM, Martijn van de Rijdt wrote: > Hi, > > Back from holiday. Thanks for sharing this. > > Re. adding new binding attributes to XLSForm: > > In my opinion, the support of bind:newattribute would be a very worthwhile > addition to XLSForm for the purpose of allowing developers to add > client-specific features without forking XLSForm (and to facilitate testing > new features during development while waiting for XLSForm support). However, > for a feature that is part of the ODK XForm and XLSForm spec (and supported > in the public ODK Collect), I think we should always add a separate column > without the bind:: prefix. It just keeps the XLSForm format a lot more > user-friendly and facilitates validation. (so XLSForm could ignore and > bind::newattribute column if newattribute has its own column in the .xls > file it's transforming). > > Re. new attributes on input/select/select1/itemset elements: > > Though the idea of using appearance parameters has a lot of appeal at first > glance, I'd like to keep appearances as simple strings without parameters > (functioning like a style class). Anything that requires parameter(s) such > as accuracyThreshold should get its own column in my opinion. For me the > issue with allowing parameters in appearances is that appearances should > ALWAYS be static for performance reasons and to keep form parsing sane. Once > you allow parameters it becomes too hard to explain why node references and > XPath functions are not allowed as appearance parameters but are allowed in > every other function in a form definition. > > Adding support for body::newattribute to XLSForm (for development or for > client-specific features) runs into a minor difficulty of what to do with > select and select1 elements as the attribute may be better placed on an > child (e.g. a search attribute). Nevertheless, it may be useful to > add this support and just add the attribute to select, select1 and input > elements only. > > Cheers, > Martijn > > PS (not directly relevant to this general XLSForm extension discussion): > > In the case of accuracyThreshold I think it would make sense to move this to > the settings column to make this a form-wide setting that could added to > h:body in XForm.) > I may be misunderstanding the autoSave feature (which would seem a great > addition) but if not, I have strong reservations about implementing this by > adding the autoSave instruction to a particular node (instead of to the > whole form). I'll save those for a different thread if the feature is meant > for the the public ODK Collect. I have the same reservation for any feature > that is dependent on a form having one question per page and requires a user > to traverse a form question by question. > > > On Saturday, July 19, 2014 6:20:45 AM UTC-6, Yaw Anokwa wrote: >> >> Agreed that we can at least standardize the ordering. I don't think it >> should be strict, but a warning seems reasonable. Ditto with >> attributes that aren't supported by all tools. >> >> Martjin? Matt? You guys have been quiet. Thoughts on how we support >> attributes going forward? >> >> Yaw >> -- >> Need ODK services? http://nafundi.com provides form design, server >> setup, professional support, and software development for ODK. >> >> On Fri, Jul 18, 2014 at 7:21 PM, Mitch Sundt wrote: >> > Chris raises an interesting issue. >> > >> > I think, however, that we want to be able to easily add columns to >> > XLSForm, >> > and Yaw's suggestion is a good one. >> > >> > We need to be able to add attributes to at least the bind element, and I >> > would argue we should allow them on the input element as well. >> > >> > The odk:length, constraintMsg and requiredMsg are all on the bind, and >> > don't >> > make sense to attach to the input element via the appearance. They >> > belong on >> > the bind. >> > >> > For Enketo and other tools that are trying to render the forms more >> > freely >> > and leverage the power of HTML and CSS, I would argue that the >> > appearance >> > attribute is too constraining. We should allow new attributes to be >> > added to >> > the input element for easier extension and development of these tools. I >> > could imagine wanting to define body::style on them, for example. >> > >> > And then there are things like the accuracy threshold for geopoints. >> > These >> > aren't constraints on the value, since a location can always be accepted >> > early by the user, so they should be tied to the input element, but they >> > don't affect appearance; they affect behavior. So it is awkward to stuff >> > them in the appearance attribute. Other examples might be resolution >> > settings for image capture and video capture, or specifications of >> > image, >> > audio, or video formats. But,given the external intent launching >> > mechanism >> > that exists within the appearance attribute, and its support of argument >> > lists, perhaps these behavioral settings, that are currently separate >> > attributes, should be moved into the argument list of the appearance >> > (e.g., >> > appearance="maps(1.5)" instead of appearance="maps" >> > accuracyThreshold="1.5"). The downside of placing everything in the >> > appearance is that you lose the readability of the XML -- you need to >> > refer >> > to our spec documents to know what 1.5 does, whereas having a separate >> > attribute provides some self-documentation. >> > >> > I don't think it is reasonable to freeze the spec and allow no new >> > attributes. Several years ago, I modified the original JR library to >> > allow >> > new attributes specifically because it didn't allow attributes like >> > odk:length on the bind. >> > >> > To Chris' point, however, we might need a .NET app or other tool that >> > will >> > unify the order and set of columns between two or more XLS forms, so >> > that >> > cutting-and-pasting will then work. And we should be clearer when we >> > update >> > our example XLS forms so that we clearly communicate the changes across >> > those versions. It would also be useful if we could collectively adopt >> > an >> > agreed-upon order of columns for all of our examples, and make them all >> > consistent, just to eliminate this point of confusion. >> > >> > Mitch >> > >> > >> > >> > On Wed, Jul 16, 2014 at 6:02 PM, Christopher Robert wrote: >> >> >> >> One argument against new-columns-for-new-attributes is that it makes it >> >> hard to have a single "template" that people can use for multiple >> >> surveys. >> >> At SurveyCTO, we early on established the norm that we'd provide form >> >> templates and users would fill them in -- without having to add >> >> columns. And >> >> then we made sure that every one of our samples used the same template. >> >> The >> >> reason was this: everybody wants to copy and paste between surveys >> >> (more or >> >> less all the time) and this leads to enormous difficulties when the set >> >> and >> >> order of columns isn't shared between the different surveys. We >> >> estimate >> >> that a large proportion of users' debugging time can easily go into >> >> debugging copy-paste problems that are themselves the result of >> >> differing >> >> column sets or orders. And that's just a terrible shame. Thus, the >> >> attempt >> >> to stamp out those errors with a single template. >> >> >> >> Now, granted, comma-delimited lists of name-value pairs is maybe hard >> >> for >> >> users to construct and debug. What if we had a series of pre-set >> >> property >> >> columns like property-name1, property-value1, property-name2, and so >> >> on? >> >> Actually, pyxform would only need to support property-name* and >> >> property-value*, and it would be up to crazy people like us to build >> >> templates with a pre-fab set of them for users to fill in. But >> >> actually, it >> >> would also be wonderful if people could easily copy and paste between >> >> ODK, >> >> formhub, Ona, Enketo, and SurveyCTO surveys... so if others wanted to >> >> jump >> >> on the "master template" idea, we could settle on a default or example >> >> template that has the same set and order of columns across our >> >> different >> >> systems. I think that everybody would benefit. >> >> >> >> Obviously, the XML format is naturally better at supporting ad-hoc >> >> attributes. I'm just trying to imagine what works well in the >> >> spreadsheet >> >> format. >> >> >> >> Best, >> >> >> >> Chris >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Jul 16, 2014 at 7:16 PM, Yaw Anokwa wrote: >> >>> >> >>> I still want there to be new columns, but we don't have to hard code >> >>> them into pyxform. >> >>> >> >>> Attributes can appear in the instance, bind, and in the body, so my >> >>> proposal is to have three new column headers that a user can add if >> >>> they want a new attribute. So, instance::$x, bind::$x, and body::$x >> >>> >> >>> So for the autocomplete example, that appears in the bind, so you'd >> >>> add a column with bind::saveIncomplete. And in the row, you'd put >> >>> true(). >> >>> >> >>> Then pyxform would know to generate this: >> >>> >> >>> >> >>> You could also then add another column with bind::myAttribute, and >> >>> then the XML would look like: >> >>> > >>> myAttribute="whatever" /> >> >>> >> >>> Again, we are adding new columns to the XLS, but we don't have to also >> >>> add them to the pyxform code. >> >>> >> >>> I think having one properties column where everything is separated by >> >>> commas seems more fragile and harder to debug. >> >>> >> >>> On Wed, Jul 16, 2014 at 10:41 AM, Matt Berg wrote: >> >>> > Can you elaborate with an xlsform example of how this would work. >> >>> > >> >>> > Instead of adding new columns we cooked add a properties column and >> >>> > have >> >>> > these be comma delimited or something like that. >> >>> > >> >>> > On Jul 16, 2014 2:56 PM, "Yaw Anokwa" wrote: >> >>> >> >> >>> >> Hi all, >> >>> >> >> >>> >> We've added true auto save to Collect. This feature was needed >> >>> >> because >> >>> >> we have a client who needs to save as incomplete at a particular >> >>> >> point >> >>> >> in the form before launching an external widget. >> >>> >> >> >>> >> The XML looks like this: >> >>> >> > >>> >> /> >> >>> >> >> >>> >> Before we push this code to trunk, we want to add support for it in >> >>> >> XLSForm. The obvious way to do this is to add a new column, but I >> >>> >> don't think it's sustainable in the long run for every attribute we >> >>> >> might want to add. >> >>> >> >> >>> >> I wanted to bring this discussion to the community to solicit >> >>> >> ideas. >> >>> >> Is the status quo of adding a named column what we want? Or do we >> >>> >> want >> >>> >> a more generic solution? >> >>> >> >> >>> >> For example, any column with body::x as a header would insert x as >> >>> >> an >> >>> >> attribute in the body XML? And bind::y would insert y as in >> >>> >> attribute >> >>> >> in the bind XML. >> >>> >> >> >>> >> Good idea? Terrible idea? >> >>> >> >> >>> >> Yaw >> >>> >> -- >> >>> >> Need ODK services? http://nafundi.com provides form design, server >> >>> >> setup, professional support, and software development for ODK. >> >>> >> >> >>> >> -- >> >>> >> 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. >> >> >> >> >> >> -- >> >> 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 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.

[martijnr]

Hi Yaw,

I'm not clear on the select/select1 issue. Can you provide an example?

E.g. if we want to properly add search() for external datasets to the spec,
we could for example decide to place it in the XForm like this (on
instead of the top-level ):

(This is just a quick example. I am not proposing this way of adding
search() support).

However, this issue is not a very good reason to not have the proposed
generic body::newatttribute feature. We can use the body::newattribute
feature for development (where it's put on the element) and if it
gets into the spec slightly adjust it.

autoSave needs to be question specific because saving takes a long

time and so you can't save on swipe. You want the form designer to
specify when the save occurs, no? Curious why this would be
problematic for you.

The key problem for me is with any features that are triggered at a
specific moment when a user traverses through a form. It's best illustrated
by imagining a form that is one giant field-list where everything is
displayed on one screen (like Enketo is by default) and users that won't
necessarily traverse the form linearly. When should the action take place?
I guess, if we accept the limitations of this (users skipping questions,
going back later, changing fill-in order), we could agree on an event that
works for all clients. Maybe this point would be when the input field gets
focus. Is this what you're thinking of?

Cheers,
Martijn

···

On Monday, July 28, 2014 2:37:59 PM UTC-6, Yaw Anokwa wrote: > > Martijn, > > Sounds like we have rough consensus on bind::newattribute. We'll start > hacking away on it and submit a patch for review. My guess is that > we'll add a whitelist of standard columns and warn (but passthrough) > on any non-standard columns. We can also probably warn on if the > ordering isn't whatever we agree on. > > I'm not clear on the select/select1 issue. Can you provide an example? > > > autoSave needs to be question specific because saving takes a long > time and so you can't save on swipe. You want the form designer to > specify when the save occurs, no? Curious why this would be > problematic for you. > > > Agreed that appearance should be static. If we need parameters for > external widgets, then that seems like the bind::newattribute is the > mechanism we should use. > > > accuracyThreshold should be question specific. I don't feel very > strongly about it, but I can imagine situations where form specific is > not adequate. > > > Yaw > > On Mon, Jul 21, 2014 at 8:23 AM, Martijn van de Rijdt <mar...@enketo.org > wrote: > > Hi, > > > > Back from holiday. Thanks for sharing this. > > > > Re. adding new binding attributes to XLSForm: > > > > In my opinion, the support of bind:newattribute would be a very > worthwhile > > addition to XLSForm for the purpose of allowing developers to add > > client-specific features without forking XLSForm (and to facilitate > testing > > new features during development while waiting for XLSForm support). > However, > > for a feature that is part of the ODK XForm and XLSForm spec (and > supported > > in the public ODK Collect), I think we should always add a separate > column > > without the bind:: prefix. It just keeps the XLSForm format a lot more > > user-friendly and facilitates validation. (so XLSForm could ignore and > > bind::newattribute column if newattribute has its own column in the .xls > > file it's transforming). > > > > Re. new attributes on input/select/select1/itemset elements: > > > > Though the idea of using appearance parameters has a lot of appeal at > first > > glance, I'd like to keep appearances as simple strings without > parameters > > (functioning like a style class). Anything that requires parameter(s) > such > > as accuracyThreshold should get its own column in my opinion. For me the > > issue with allowing parameters in appearances is that appearances should > > ALWAYS be static for performance reasons and to keep form parsing sane. > Once > > you allow parameters it becomes too hard to explain why node references > and > > XPath functions are not allowed as appearance parameters but are allowed > in > > every other function in a form definition. > > > > Adding support for body::newattribute to XLSForm (for development or for > > client-specific features) runs into a minor difficulty of what to do > with > > select and select1 elements as the attribute may be better placed on an > > child (e.g. a search attribute). Nevertheless, it may be > useful to > > add this support and just add the attribute to select, select1 and input > > elements only. > > > > Cheers, > > Martijn > > > > PS (not directly relevant to this general XLSForm extension discussion): > > > > In the case of accuracyThreshold I think it would make sense to move > this to > > the settings column to make this a form-wide setting that could added to > > h:body in XForm.) > > I may be misunderstanding the autoSave feature (which would seem a great > > addition) but if not, I have strong reservations about implementing this > by > > adding the autoSave instruction to a particular node (instead of to the > > whole form). I'll save those for a different thread if the feature is > meant > > for the the public ODK Collect. I have the same reservation for any > feature > > that is dependent on a form having one question per page and requires a > user > > to traverse a form question by question. > > > > > > On Saturday, July 19, 2014 6:20:45 AM UTC-6, Yaw Anokwa wrote: > >> > >> Agreed that we can at least standardize the ordering. I don't think it > >> should be strict, but a warning seems reasonable. Ditto with > >> attributes that aren't supported by all tools. > >> > >> Martjin? Matt? You guys have been quiet. Thoughts on how we support > >> attributes going forward? > >> > >> Yaw > >> -- > >> Need ODK services? http://nafundi.com provides form design, server > >> setup, professional support, and software development for ODK. > >> > >> On Fri, Jul 18, 2014 at 7:21 PM, Mitch Sundt wrote: > >> > Chris raises an interesting issue. > >> > > >> > I think, however, that we want to be able to easily add columns to > >> > XLSForm, > >> > and Yaw's suggestion is a good one. > >> > > >> > We need to be able to add attributes to at least the bind element, > and I > >> > would argue we should allow them on the input element as well. > >> > > >> > The odk:length, constraintMsg and requiredMsg are all on the bind, > and > >> > don't > >> > make sense to attach to the input element via the appearance. They > >> > belong on > >> > the bind. > >> > > >> > For Enketo and other tools that are trying to render the forms more > >> > freely > >> > and leverage the power of HTML and CSS, I would argue that the > >> > appearance > >> > attribute is too constraining. We should allow new attributes to be > >> > added to > >> > the input element for easier extension and development of these > tools. I > >> > could imagine wanting to define body::style on them, for example. > >> > > >> > And then there are things like the accuracy threshold for geopoints. > >> > These > >> > aren't constraints on the value, since a location can always be > accepted > >> > early by the user, so they should be tied to the input element, but > they > >> > don't affect appearance; they affect behavior. So it is awkward to > stuff > >> > them in the appearance attribute. Other examples might be resolution > >> > settings for image capture and video capture, or specifications of > >> > image, > >> > audio, or video formats. But,given the external intent launching > >> > mechanism > >> > that exists within the appearance attribute, and its support of > argument > >> > lists, perhaps these behavioral settings, that are currently separate > >> > attributes, should be moved into the argument list of the appearance > >> > (e.g., > >> > appearance="maps(1.5)" instead of appearance="maps" > >> > accuracyThreshold="1.5"). The downside of placing everything in the > >> > appearance is that you lose the readability of the XML -- you need to > >> > refer > >> > to our spec documents to know what 1.5 does, whereas having a > separate > >> > attribute provides some self-documentation. > >> > > >> > I don't think it is reasonable to freeze the spec and allow no new > >> > attributes. Several years ago, I modified the original JR library to > >> > allow > >> > new attributes specifically because it didn't allow attributes like > >> > odk:length on the bind. > >> > > >> > To Chris' point, however, we might need a .NET app or other tool that > >> > will > >> > unify the order and set of columns between two or more XLS forms, so > >> > that > >> > cutting-and-pasting will then work. And we should be clearer when we > >> > update > >> > our example XLS forms so that we clearly communicate the changes > across > >> > those versions. It would also be useful if we could collectively > adopt > >> > an > >> > agreed-upon order of columns for all of our examples, and make them > all > >> > consistent, just to eliminate this point of confusion. > >> > > >> > Mitch > >> > > >> > > >> > > >> > On Wed, Jul 16, 2014 at 6:02 PM, Christopher Robert wrote: > >> >> > >> >> One argument against new-columns-for-new-attributes is that it makes > it > >> >> hard to have a single "template" that people can use for multiple > >> >> surveys. > >> >> At SurveyCTO, we early on established the norm that we'd provide > form > >> >> templates and users would fill them in -- without having to add > >> >> columns. And > >> >> then we made sure that every one of our samples used the same > template. > >> >> The > >> >> reason was this: everybody wants to copy and paste between surveys > >> >> (more or > >> >> less all the time) and this leads to enormous difficulties when the > set > >> >> and > >> >> order of columns isn't shared between the different surveys. We > >> >> estimate > >> >> that a large proportion of users' debugging time can easily go into > >> >> debugging copy-paste problems that are themselves the result of > >> >> differing > >> >> column sets or orders. And that's just a terrible shame. Thus, the > >> >> attempt > >> >> to stamp out those errors with a single template. > >> >> > >> >> Now, granted, comma-delimited lists of name-value pairs is maybe > hard > >> >> for > >> >> users to construct and debug. What if we had a series of pre-set > >> >> property > >> >> columns like property-name1, property-value1, property-name2, and so > >> >> on? > >> >> Actually, pyxform would only need to support property-name* and > >> >> property-value*, and it would be up to crazy people like us to build > >> >> templates with a pre-fab set of them for users to fill in. But > >> >> actually, it > >> >> would also be wonderful if people could easily copy and paste > between > >> >> ODK, > >> >> formhub, Ona, Enketo, and SurveyCTO surveys... so if others wanted > to > >> >> jump > >> >> on the "master template" idea, we could settle on a default or > example > >> >> template that has the same set and order of columns across our > >> >> different > >> >> systems. I think that everybody would benefit. > >> >> > >> >> Obviously, the XML format is naturally better at supporting ad-hoc > >> >> attributes. I'm just trying to imagine what works well in the > >> >> spreadsheet > >> >> format. > >> >> > >> >> Best, > >> >> > >> >> Chris > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> On Wed, Jul 16, 2014 at 7:16 PM, Yaw Anokwa wrote: > >> >>> > >> >>> I still want there to be new columns, but we don't have to hard > code > >> >>> them into pyxform. > >> >>> > >> >>> Attributes can appear in the instance, bind, and in the body, so my > >> >>> proposal is to have three new column headers that a user can add if > >> >>> they want a new attribute. So, instance::$x, bind::$x, and body::$x > >> >>> > >> >>> So for the autocomplete example, that appears in the bind, so you'd > >> >>> add a column with bind::saveIncomplete. And in the row, you'd put > >> >>> true(). > >> >>> > >> >>> Then pyxform would know to generate this: > >> >>> /> > >> >>> > >> >>> You could also then add another column with bind::myAttribute, and > >> >>> then the XML would look like: > >> >>> >> >>> myAttribute="whatever" /> > >> >>> > >> >>> Again, we are adding new columns to the XLS, but we don't have to > also > >> >>> add them to the pyxform code. > >> >>> > >> >>> I think having one properties column where everything is separated > by > >> >>> commas seems more fragile and harder to debug. > >> >>> > >> >>> On Wed, Jul 16, 2014 at 10:41 AM, Matt Berg wrote: > >> >>> > Can you elaborate with an xlsform example of how this would work. > >> >>> > > >> >>> > Instead of adding new columns we cooked add a properties column > and > >> >>> > have > >> >>> > these be comma delimited or something like that. > >> >>> > > >> >>> > On Jul 16, 2014 2:56 PM, "Yaw Anokwa" wrote: > >> >>> >> > >> >>> >> Hi all, > >> >>> >> > >> >>> >> We've added true auto save to Collect. This feature was needed > >> >>> >> because > >> >>> >> we have a client who needs to save as incomplete at a particular > >> >>> >> point > >> >>> >> in the form before launching an external widget. > >> >>> >> > >> >>> >> The XML looks like this: > >> >>> >> saveIncomplete="true()" > >> >>> >> /> > >> >>> >> > >> >>> >> Before we push this code to trunk, we want to add support for it > in > >> >>> >> XLSForm. The obvious way to do this is to add a new column, but > I > >> >>> >> don't think it's sustainable in the long run for every attribute > we > >> >>> >> might want to add. > >> >>> >> > >> >>> >> I wanted to bring this discussion to the community to solicit > >> >>> >> ideas. > >> >>> >> Is the status quo of adding a named column what we want? Or do > we > >> >>> >> want > >> >>> >> a more generic solution? > >> >>> >> > >> >>> >> For example, any column with body::x as a header would insert x > as > >> >>> >> an > >> >>> >> attribute in the body XML? And bind::y would insert y as in > >> >>> >> attribute > >> >>> >> in the bind XML. > >> >>> >> > >> >>> >> Good idea? Terrible idea? > >> >>> >> > >> >>> >> Yaw > >> >>> >> -- > >> >>> >> Need ODK services? http://nafundi.com provides form design, > server > >> >>> >> setup, professional support, and software development for ODK. > >> >>> >> > >> >>> >> -- > >> >>> >> 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. > >> >> > >> >> > >> >> -- > >> >> 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 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. >

[yanokwa]

Thanks for clarifying the select issue. I agree that it's not a blocker.

Saving when input field gets focus sounds like a nice solution for
Enketo. Or you can also ignore the tag and auto save on every change
if that's a lightweight operation for you.

Yaw

···

-- Need ODK services? http://nafundi.com provides form design, server setup, professional support, and software development for ODK.

On Tue, Jul 29, 2014 at 9:18 AM, Martijn van de Rijdt martijn@enketo.org wrote:

Hi Yaw,

I'm not clear on the select/select1 issue. Can you provide an example?

E.g. if we want to properly add search() for external datasets to the spec,
we could for example decide to place it in the XForm like this (on
instead of the top-level ):

(This is just a quick example. I am not proposing this way of adding
search() support).

However, this issue is not a very good reason to not have the proposed
generic body::newatttribute feature. We can use the body::newattribute
feature for development (where it's put on the element) and if it
gets into the spec slightly adjust it.

autoSave needs to be question specific because saving takes a long
time and so you can't save on swipe. You want the form designer to
specify when the save occurs, no? Curious why this would be
problematic for you.

The key problem for me is with any features that are triggered at a specific
moment when a user traverses through a form. It's best illustrated by
imagining a form that is one giant field-list where everything is displayed
on one screen (like Enketo is by default) and users that won't necessarily
traverse the form linearly. When should the action take place? I guess, if
we accept the limitations of this (users skipping questions, going back
later, changing fill-in order), we could agree on an event that works for
all clients. Maybe this point would be when the input field gets focus. Is
this what you're thinking of?

Cheers,
Martijn

On Monday, July 28, 2014 2:37:59 PM UTC-6, Yaw Anokwa wrote:

Martijn,

Sounds like we have rough consensus on bind::newattribute. We'll start
hacking away on it and submit a patch for review. My guess is that
we'll add a whitelist of standard columns and warn (but passthrough)
on any non-standard columns. We can also probably warn on if the
ordering isn't whatever we agree on.

I'm not clear on the select/select1 issue. Can you provide an example?

autoSave needs to be question specific because saving takes a long
time and so you can't save on swipe. You want the form designer to
specify when the save occurs, no? Curious why this would be
problematic for you.

Agreed that appearance should be static. If we need parameters for
external widgets, then that seems like the bind::newattribute is the
mechanism we should use.

accuracyThreshold should be question specific. I don't feel very
strongly about it, but I can imagine situations where form specific is
not adequate.

Yaw

On Mon, Jul 21, 2014 at 8:23 AM, Martijn van de Rijdt mar...@enketo.org wrote:

Hi,

Back from holiday. Thanks for sharing this.

Re. adding new binding attributes to XLSForm:

In my opinion, the support of bind:newattribute would be a very
worthwhile
addition to XLSForm for the purpose of allowing developers to add
client-specific features without forking XLSForm (and to facilitate
testing
new features during development while waiting for XLSForm support).
However,
for a feature that is part of the ODK XForm and XLSForm spec (and
supported
in the public ODK Collect), I think we should always add a separate
column
without the bind:: prefix. It just keeps the XLSForm format a lot more
user-friendly and facilitates validation. (so XLSForm could ignore and
bind::newattribute column if newattribute has its own column in the .xls
file it's transforming).

Re. new attributes on input/select/select1/itemset elements:

Though the idea of using appearance parameters has a lot of appeal at
first
glance, I'd like to keep appearances as simple strings without
parameters
(functioning like a style class). Anything that requires parameter(s)
such
as accuracyThreshold should get its own column in my opinion. For me the
issue with allowing parameters in appearances is that appearances should
ALWAYS be static for performance reasons and to keep form parsing sane.
Once
you allow parameters it becomes too hard to explain why node references
and
XPath functions are not allowed as appearance parameters but are allowed
in
every other function in a form definition.

Adding support for body::newattribute to XLSForm (for development or for
client-specific features) runs into a minor difficulty of what to do
with
select and select1 elements as the attribute may be better placed on an
child (e.g. a search attribute). Nevertheless, it may be
useful to
add this support and just add the attribute to select, select1 and input
elements only.

Cheers,
Martijn

PS (not directly relevant to this general XLSForm extension discussion):

In the case of accuracyThreshold I think it would make sense to move
this to
the settings column to make this a form-wide setting that could added to
h:body in XForm.)
I may be misunderstanding the autoSave feature (which would seem a great
addition) but if not, I have strong reservations about implementing this
by
adding the autoSave instruction to a particular node (instead of to the
whole form). I'll save those for a different thread if the feature is
meant
for the the public ODK Collect. I have the same reservation for any
feature
that is dependent on a form having one question per page and requires a
user
to traverse a form question by question.

On Saturday, July 19, 2014 6:20:45 AM UTC-6, Yaw Anokwa wrote:

Agreed that we can at least standardize the ordering. I don't think it
should be strict, but a warning seems reasonable. Ditto with
attributes that aren't supported by all tools.

Martjin? Matt? You guys have been quiet. Thoughts on how we support
attributes going forward?

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

On Fri, Jul 18, 2014 at 7:21 PM, Mitch Sundt mitche...@gmail.com wrote:

Chris raises an interesting issue.

I think, however, that we want to be able to easily add columns to
XLSForm,
and Yaw's suggestion is a good one.

We need to be able to add attributes to at least the bind element,
and I
would argue we should allow them on the input element as well.

The odk:length, constraintMsg and requiredMsg are all on the bind,
and
don't
make sense to attach to the input element via the appearance. They
belong on
the bind.

For Enketo and other tools that are trying to render the forms more
freely
and leverage the power of HTML and CSS, I would argue that the
appearance
attribute is too constraining. We should allow new attributes to be
added to
the input element for easier extension and development of these
tools. I
could imagine wanting to define body::style on them, for example.

And then there are things like the accuracy threshold for geopoints.
These
aren't constraints on the value, since a location can always be
accepted
early by the user, so they should be tied to the input element, but
they
don't affect appearance; they affect behavior. So it is awkward to
stuff
them in the appearance attribute. Other examples might be resolution
settings for image capture and video capture, or specifications of
image,
audio, or video formats. But,given the external intent launching
mechanism
that exists within the appearance attribute, and its support of
argument
lists, perhaps these behavioral settings, that are currently separate
attributes, should be moved into the argument list of the appearance
(e.g.,
appearance="maps(1.5)" instead of appearance="maps"
accuracyThreshold="1.5"). The downside of placing everything in the
appearance is that you lose the readability of the XML -- you need to
refer
to our spec documents to know what 1.5 does, whereas having a
separate
attribute provides some self-documentation.

I don't think it is reasonable to freeze the spec and allow no new
attributes. Several years ago, I modified the original JR library to
allow
new attributes specifically because it didn't allow attributes like
odk:length on the bind.

To Chris' point, however, we might need a .NET app or other tool that
will
unify the order and set of columns between two or more XLS forms, so
that
cutting-and-pasting will then work. And we should be clearer when we
update
our example XLS forms so that we clearly communicate the changes
across
those versions. It would also be useful if we could collectively
adopt
an
agreed-upon order of columns for all of our examples, and make them
all
consistent, just to eliminate this point of confusion.

Mitch

On Wed, Jul 16, 2014 at 6:02 PM, Christopher Robert cro...@surveycto.com wrote:

One argument against new-columns-for-new-attributes is that it makes
it
hard to have a single "template" that people can use for multiple
surveys.
At SurveyCTO, we early on established the norm that we'd provide
form
templates and users would fill them in -- without having to add
columns. And
then we made sure that every one of our samples used the same
template.
The
reason was this: everybody wants to copy and paste between surveys
(more or
less all the time) and this leads to enormous difficulties when the
set
and
order of columns isn't shared between the different surveys. We
estimate
that a large proportion of users' debugging time can easily go into
debugging copy-paste problems that are themselves the result of
differing
column sets or orders. And that's just a terrible shame. Thus, the
attempt
to stamp out those errors with a single template.

Now, granted, comma-delimited lists of name-value pairs is maybe
hard
for
users to construct and debug. What if we had a series of pre-set
property
columns like property-name1, property-value1, property-name2, and so
on?
Actually, pyxform would only need to support property-name* and
property-value*, and it would be up to crazy people like us to build
templates with a pre-fab set of them for users to fill in. But
actually, it
would also be wonderful if people could easily copy and paste
between
ODK,
formhub, Ona, Enketo, and SurveyCTO surveys... so if others wanted
to
jump
on the "master template" idea, we could settle on a default or
example
template that has the same set and order of columns across our
different
systems. I think that everybody would benefit.

Obviously, the XML format is naturally better at supporting ad-hoc
attributes. I'm just trying to imagine what works well in the
spreadsheet
format.

Best,

Chris

On Wed, Jul 16, 2014 at 7:16 PM, Yaw Anokwa yan...@nafundi.com wrote:

I still want there to be new columns, but we don't have to hard
code
them into pyxform.

Attributes can appear in the instance, bind, and in the body, so my
proposal is to have three new column headers that a user can add if
they want a new attribute. So, instance::$x, bind::$x, and body::$x

So for the autocomplete example, that appears in the bind, so you'd
add a column with bind::saveIncomplete. And in the row, you'd put
true().

Then pyxform would know to generate this:

You could also then add another column with bind::myAttribute, and
then the XML would look like:

Again, we are adding new columns to the XLS, but we don't have to
also
add them to the pyxform code.

I think having one properties column where everything is separated
by
commas seems more fragile and harder to debug.

On Wed, Jul 16, 2014 at 10:41 AM, Matt Berg mlb...@gmail.com wrote:

Can you elaborate with an xlsform example of how this would work.

Instead of adding new columns we cooked add a properties column
and
have
these be comma delimited or something like that.

On Jul 16, 2014 2:56 PM, "Yaw Anokwa" yan...@nafundi.com wrote:

Hi all,

We've added true auto save to Collect. This feature was needed
because
we have a client who needs to save as incomplete at a particular
point
in the form before launching an external widget.

The XML looks like this:

Before we push this code to trunk, we want to add support for it
in
XLSForm. The obvious way to do this is to add a new column, but
I
don't think it's sustainable in the long run for every attribute
we
might want to add.

I wanted to bring this discussion to the community to solicit
ideas.
Is the status quo of adding a named column what we want? Or do
we
want
a more generic solution?

For example, any column with body::x as a header would insert x
as
an
attribute in the body XML? And bind::y would insert y as in
attribute
in the bind XML.

Good idea? Terrible idea?

Yaw

Need ODK services? http://nafundi.com provides form design,
server
setup, professional support, and software development for ODK.

--
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.

--
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 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.

[martijnr]

Are you not using the focus event yourself? If not, what is the event that
triggers the autoSave if this question is in the middle of a field-list of
questions that are all displayed on the same page?

···

On Tue, Jul 29, 2014 at 2:48 PM, Yaw Anokwa wrote:

Thanks for clarifying the select issue. I agree that it's not a blocker.

Saving when input field gets focus sounds like a nice solution for
Enketo. Or you can also ignore the tag and auto save on every change
if that's a lightweight operation for you.

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

On Tue, Jul 29, 2014 at 9:18 AM, Martijn van de Rijdt martijn@enketo.org wrote:

Hi Yaw,

I'm not clear on the select/select1 issue. Can you provide an example?

E.g. if we want to properly add search() for external datasets to the
spec,
we could for example decide to place it in the XForm like this (on

instead of the top-level ):

(This is just a quick example. I am not proposing this way of adding
search() support).

However, this issue is not a very good reason to not have the proposed
generic body::newatttribute feature. We can use the body::newattribute
feature for development (where it's put on the element) and if
it
gets into the spec slightly adjust it.

autoSave needs to be question specific because saving takes a long
time and so you can't save on swipe. You want the form designer to
specify when the save occurs, no? Curious why this would be
problematic for you.

The key problem for me is with any features that are triggered at a
specific
moment when a user traverses through a form. It's best illustrated by
imagining a form that is one giant field-list where everything is
displayed
on one screen (like Enketo is by default) and users that won't
necessarily
traverse the form linearly. When should the action take place? I guess,
if
we accept the limitations of this (users skipping questions, going back
later, changing fill-in order), we could agree on an event that works for
all clients. Maybe this point would be when the input field gets focus.
Is
this what you're thinking of?

Cheers,
Martijn

On Monday, July 28, 2014 2:37:59 PM UTC-6, Yaw Anokwa wrote:

Martijn,

Sounds like we have rough consensus on bind::newattribute. We'll start
hacking away on it and submit a patch for review. My guess is that
we'll add a whitelist of standard columns and warn (but passthrough)
on any non-standard columns. We can also probably warn on if the
ordering isn't whatever we agree on.

I'm not clear on the select/select1 issue. Can you provide an example?

autoSave needs to be question specific because saving takes a long
time and so you can't save on swipe. You want the form designer to
specify when the save occurs, no? Curious why this would be
problematic for you.

Agreed that appearance should be static. If we need parameters for
external widgets, then that seems like the bind::newattribute is the
mechanism we should use.

accuracyThreshold should be question specific. I don't feel very
strongly about it, but I can imagine situations where form specific is
not adequate.

Yaw

On Mon, Jul 21, 2014 at 8:23 AM, Martijn van de Rijdt mar...@enketo.org wrote:

Hi,

Back from holiday. Thanks for sharing this.

Re. adding new binding attributes to XLSForm:

In my opinion, the support of bind:newattribute would be a very
worthwhile
addition to XLSForm for the purpose of allowing developers to add
client-specific features without forking XLSForm (and to facilitate
testing
new features during development while waiting for XLSForm support).
However,
for a feature that is part of the ODK XForm and XLSForm spec (and
supported
in the public ODK Collect), I think we should always add a separate
column
without the bind:: prefix. It just keeps the XLSForm format a lot more
user-friendly and facilitates validation. (so XLSForm could ignore and
bind::newattribute column if newattribute has its own column in the
.xls

file it's transforming).

Re. new attributes on input/select/select1/itemset elements:

Though the idea of using appearance parameters has a lot of appeal at
first
glance, I'd like to keep appearances as simple strings without
parameters
(functioning like a style class). Anything that requires parameter(s)
such
as accuracyThreshold should get its own column in my opinion. For me
the

issue with allowing parameters in appearances is that appearances
should

ALWAYS be static for performance reasons and to keep form parsing
sane.

Once
you allow parameters it becomes too hard to explain why node
references

and
XPath functions are not allowed as appearance parameters but are
allowed

in
every other function in a form definition.

Adding support for body::newattribute to XLSForm (for development or
for

client-specific features) runs into a minor difficulty of what to do
with
select and select1 elements as the attribute may be better placed on
an

child (e.g. a search attribute). Nevertheless, it may be
useful to
add this support and just add the attribute to select, select1 and
input

elements only.

Cheers,
Martijn

PS (not directly relevant to this general XLSForm extension
discussion):

In the case of accuracyThreshold I think it would make sense to move
this to
the settings column to make this a form-wide setting that could added
to

h:body in XForm.)
I may be misunderstanding the autoSave feature (which would seem a
great

addition) but if not, I have strong reservations about implementing
this

by
adding the autoSave instruction to a particular node (instead of to
the

whole form). I'll save those for a different thread if the feature is
meant
for the the public ODK Collect. I have the same reservation for any
feature
that is dependent on a form having one question per page and requires
a

user
to traverse a form question by question.

On Saturday, July 19, 2014 6:20:45 AM UTC-6, Yaw Anokwa wrote:

Agreed that we can at least standardize the ordering. I don't think
it

should be strict, but a warning seems reasonable. Ditto with
attributes that aren't supported by all tools.

Martjin? Matt? You guys have been quiet. Thoughts on how we support
attributes going forward?

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

On Fri, Jul 18, 2014 at 7:21 PM, Mitch Sundt mitche...@gmail.com wrote:

Chris raises an interesting issue.

I think, however, that we want to be able to easily add columns to
XLSForm,
and Yaw's suggestion is a good one.

We need to be able to add attributes to at least the bind element,
and I
would argue we should allow them on the input element as well.

The odk:length, constraintMsg and requiredMsg are all on the bind,
and
don't
make sense to attach to the input element via the appearance. They
belong on
the bind.

For Enketo and other tools that are trying to render the forms more
freely
and leverage the power of HTML and CSS, I would argue that the
appearance
attribute is too constraining. We should allow new attributes to be
added to
the input element for easier extension and development of these
tools. I
could imagine wanting to define body::style on them, for example.

And then there are things like the accuracy threshold for
geopoints.

These
aren't constraints on the value, since a location can always be
accepted
early by the user, so they should be tied to the input element, but
they
don't affect appearance; they affect behavior. So it is awkward to
stuff
them in the appearance attribute. Other examples might be
resolution

settings for image capture and video capture, or specifications of
image,
audio, or video formats. But,given the external intent launching
mechanism
that exists within the appearance attribute, and its support of
argument
lists, perhaps these behavioral settings, that are currently
separate

attributes, should be moved into the argument list of the
appearance

(e.g.,
appearance="maps(1.5)" instead of appearance="maps"
accuracyThreshold="1.5"). The downside of placing everything in
the

appearance is that you lose the readability of the XML -- you need
to

refer
to our spec documents to know what 1.5 does, whereas having a
separate
attribute provides some self-documentation.

I don't think it is reasonable to freeze the spec and allow no new
attributes. Several years ago, I modified the original JR library
to

allow
new attributes specifically because it didn't allow attributes like
odk:length on the bind.

To Chris' point, however, we might need a .NET app or other tool
that

will
unify the order and set of columns between two or more XLS forms,
so

that
cutting-and-pasting will then work. And we should be clearer when
we

update
our example XLS forms so that we clearly communicate the changes
across
those versions. It would also be useful if we could collectively
adopt
an
agreed-upon order of columns for all of our examples, and make them
all
consistent, just to eliminate this point of confusion.

Mitch

On Wed, Jul 16, 2014 at 6:02 PM, Christopher Robert cro...@surveycto.com wrote:

One argument against new-columns-for-new-attributes is that it
makes

it
hard to have a single "template" that people can use for multiple
surveys.
At SurveyCTO, we early on established the norm that we'd provide
form
templates and users would fill them in -- without having to add
columns. And
then we made sure that every one of our samples used the same
template.
The
reason was this: everybody wants to copy and paste between surveys
(more or
less all the time) and this leads to enormous difficulties when
the

set
and
order of columns isn't shared between the different surveys. We
estimate
that a large proportion of users' debugging time can easily go
into

debugging copy-paste problems that are themselves the result of
differing
column sets or orders. And that's just a terrible shame. Thus, the
attempt
to stamp out those errors with a single template.

Now, granted, comma-delimited lists of name-value pairs is maybe
hard
for
users to construct and debug. What if we had a series of pre-set
property
columns like property-name1, property-value1, property-name2, and
so

on?
Actually, pyxform would only need to support property-name* and
property-value*, and it would be up to crazy people like us to
build

templates with a pre-fab set of them for users to fill in. But
actually, it
would also be wonderful if people could easily copy and paste
between
ODK,
formhub, Ona, Enketo, and SurveyCTO surveys... so if others wanted
to
jump
on the "master template" idea, we could settle on a default or
example
template that has the same set and order of columns across our
different
systems. I think that everybody would benefit.

Obviously, the XML format is naturally better at supporting ad-hoc
attributes. I'm just trying to imagine what works well in the
spreadsheet
format.

Best,

Chris

On Wed, Jul 16, 2014 at 7:16 PM, Yaw Anokwa yan...@nafundi.com wrote:

I still want there to be new columns, but we don't have to hard
code
them into pyxform.

Attributes can appear in the instance, bind, and in the body, so
my

proposal is to have three new column headers that a user can add
if

they want a new attribute. So, instance::$x, bind::$x, and
body::$x

So for the autocomplete example, that appears in the bind, so
you'd

add a column with bind::saveIncomplete. And in the row, you'd put
true().

Then pyxform would know to generate this:

You could also then add another column with bind::myAttribute,
and

then the XML would look like:

Again, we are adding new columns to the XLS, but we don't have to
also
add them to the pyxform code.

I think having one properties column where everything is
separated

by
commas seems more fragile and harder to debug.

On Wed, Jul 16, 2014 at 10:41 AM, Matt Berg mlb...@gmail.com wrote:

Can you elaborate with an xlsform example of how this would
work.

Instead of adding new columns we cooked add a properties column
and
have
these be comma delimited or something like that.

On Jul 16, 2014 2:56 PM, "Yaw Anokwa" yan...@nafundi.com wrote:

Hi all,

We've added true auto save to Collect. This feature was needed
because
we have a client who needs to save as incomplete at a
particular

point
in the form before launching an external widget.

The XML looks like this:

Before we push this code to trunk, we want to add support for
it

in
XLSForm. The obvious way to do this is to add a new column,
but

I
don't think it's sustainable in the long run for every
attribute

we
might want to add.

I wanted to bring this discussion to the community to solicit
ideas.
Is the status quo of adding a named column what we want? Or do
we
want
a more generic solution?

For example, any column with body::x as a header would insert
x

as
an
attribute in the body XML? And bind::y would insert y as in
attribute
in the bind XML.

Good idea? Terrible idea?

Yaw

Need ODK services? http://nafundi.com provides form design,
server
setup, professional support, and software development for ODK.

--
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.

--
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 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.

--
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/hgAXcRBkmAs/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.

--
Did you know that Enketo Smart Paper has now become the #1 tool for data
collection? Don't fall behind. Use it!

Enketo https://enketo.org | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/MartijnR | Twitter https://twitter.com/enketo

[yanokwa]

Martijn,

I believe it does the save when the field-list finishes rendering.

Yaw

···

-- Need ODK services? http://nafundi.com provides form design, server setup, professional support, and software development for ODK.

On Tue, Jul 29, 2014 at 2:26 PM, Martijn van de Rijdt martijn@enketo.org wrote:

Are you not using the focus event yourself? If not, what is the event that
triggers the autoSave if this question is in the middle of a field-list of
questions that are all displayed on the same page?

On Tue, Jul 29, 2014 at 2:48 PM, Yaw Anokwa yanokwa@nafundi.com wrote:

Thanks for clarifying the select issue. I agree that it's not a blocker.

Saving when input field gets focus sounds like a nice solution for
Enketo. Or you can also ignore the tag and auto save on every change
if that's a lightweight operation for you.

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

On Tue, Jul 29, 2014 at 9:18 AM, Martijn van de Rijdt martijn@enketo.org wrote:

Hi Yaw,

I'm not clear on the select/select1 issue. Can you provide an example?

E.g. if we want to properly add search() for external datasets to the
spec,
we could for example decide to place it in the XForm like this (on

instead of the top-level ):

(This is just a quick example. I am not proposing this way of adding
search() support).

However, this issue is not a very good reason to not have the proposed
generic body::newatttribute feature. We can use the body::newattribute
feature for development (where it's put on the element) and if
it
gets into the spec slightly adjust it.

autoSave needs to be question specific because saving takes a long
time and so you can't save on swipe. You want the form designer to
specify when the save occurs, no? Curious why this would be
problematic for you.

The key problem for me is with any features that are triggered at a
specific
moment when a user traverses through a form. It's best illustrated by
imagining a form that is one giant field-list where everything is
displayed
on one screen (like Enketo is by default) and users that won't
necessarily
traverse the form linearly. When should the action take place? I guess,
if
we accept the limitations of this (users skipping questions, going back
later, changing fill-in order), we could agree on an event that works
for
all clients. Maybe this point would be when the input field gets focus.
Is
this what you're thinking of?

Cheers,
Martijn

On Monday, July 28, 2014 2:37:59 PM UTC-6, Yaw Anokwa wrote:

Martijn,

Sounds like we have rough consensus on bind::newattribute. We'll start
hacking away on it and submit a patch for review. My guess is that
we'll add a whitelist of standard columns and warn (but passthrough)
on any non-standard columns. We can also probably warn on if the
ordering isn't whatever we agree on.

I'm not clear on the select/select1 issue. Can you provide an example?

autoSave needs to be question specific because saving takes a long
time and so you can't save on swipe. You want the form designer to
specify when the save occurs, no? Curious why this would be
problematic for you.

Agreed that appearance should be static. If we need parameters for
external widgets, then that seems like the bind::newattribute is the
mechanism we should use.

accuracyThreshold should be question specific. I don't feel very
strongly about it, but I can imagine situations where form specific is
not adequate.

Yaw

On Mon, Jul 21, 2014 at 8:23 AM, Martijn van de Rijdt mar...@enketo.org wrote:

Hi,

Back from holiday. Thanks for sharing this.

Re. adding new binding attributes to XLSForm:

In my opinion, the support of bind:newattribute would be a very
worthwhile
addition to XLSForm for the purpose of allowing developers to add
client-specific features without forking XLSForm (and to facilitate
testing
new features during development while waiting for XLSForm support).
However,
for a feature that is part of the ODK XForm and XLSForm spec (and
supported
in the public ODK Collect), I think we should always add a separate
column
without the bind:: prefix. It just keeps the XLSForm format a lot
more
user-friendly and facilitates validation. (so XLSForm could ignore
and
bind::newattribute column if newattribute has its own column in the
.xls
file it's transforming).

Re. new attributes on input/select/select1/itemset elements:

Though the idea of using appearance parameters has a lot of appeal at
first
glance, I'd like to keep appearances as simple strings without
parameters
(functioning like a style class). Anything that requires parameter(s)
such
as accuracyThreshold should get its own column in my opinion. For me
the
issue with allowing parameters in appearances is that appearances
should
ALWAYS be static for performance reasons and to keep form parsing
sane.
Once
you allow parameters it becomes too hard to explain why node
references
and
XPath functions are not allowed as appearance parameters but are
allowed
in
every other function in a form definition.

Adding support for body::newattribute to XLSForm (for development or
for
client-specific features) runs into a minor difficulty of what to do
with
select and select1 elements as the attribute may be better placed on
an
child (e.g. a search attribute). Nevertheless, it may be
useful to
add this support and just add the attribute to select, select1 and
input
elements only.

Cheers,
Martijn

PS (not directly relevant to this general XLSForm extension
discussion):

In the case of accuracyThreshold I think it would make sense to move
this to
the settings column to make this a form-wide setting that could added
to
h:body in XForm.)
I may be misunderstanding the autoSave feature (which would seem a
great
addition) but if not, I have strong reservations about implementing
this
by
adding the autoSave instruction to a particular node (instead of to
the
whole form). I'll save those for a different thread if the feature is
meant
for the the public ODK Collect. I have the same reservation for any
feature
that is dependent on a form having one question per page and requires
a
user
to traverse a form question by question.

On Saturday, July 19, 2014 6:20:45 AM UTC-6, Yaw Anokwa wrote:

Agreed that we can at least standardize the ordering. I don't think
it
should be strict, but a warning seems reasonable. Ditto with
attributes that aren't supported by all tools.

Martjin? Matt? You guys have been quiet. Thoughts on how we support
attributes going forward?

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

On Fri, Jul 18, 2014 at 7:21 PM, Mitch Sundt mitche...@gmail.com wrote:

Chris raises an interesting issue.

I think, however, that we want to be able to easily add columns to
XLSForm,
and Yaw's suggestion is a good one.

We need to be able to add attributes to at least the bind element,
and I
would argue we should allow them on the input element as well.

The odk:length, constraintMsg and requiredMsg are all on the bind,
and
don't
make sense to attach to the input element via the appearance. They
belong on
the bind.

For Enketo and other tools that are trying to render the forms
more
freely
and leverage the power of HTML and CSS, I would argue that the
appearance
attribute is too constraining. We should allow new attributes to
be
added to
the input element for easier extension and development of these
tools. I
could imagine wanting to define body::style on them, for example.

And then there are things like the accuracy threshold for
geopoints.
These
aren't constraints on the value, since a location can always be
accepted
early by the user, so they should be tied to the input element,
but
they
don't affect appearance; they affect behavior. So it is awkward to
stuff
them in the appearance attribute. Other examples might be
resolution
settings for image capture and video capture, or specifications of
image,
audio, or video formats. But,given the external intent launching
mechanism
that exists within the appearance attribute, and its support of
argument
lists, perhaps these behavioral settings, that are currently
separate
attributes, should be moved into the argument list of the
appearance
(e.g.,
appearance="maps(1.5)" instead of appearance="maps"
accuracyThreshold="1.5"). The downside of placing everything in
the
appearance is that you lose the readability of the XML -- you need
to
refer
to our spec documents to know what 1.5 does, whereas having a
separate
attribute provides some self-documentation.

I don't think it is reasonable to freeze the spec and allow no new
attributes. Several years ago, I modified the original JR library
to
allow
new attributes specifically because it didn't allow attributes
like
odk:length on the bind.

To Chris' point, however, we might need a .NET app or other tool
that
will
unify the order and set of columns between two or more XLS forms,
so
that
cutting-and-pasting will then work. And we should be clearer when
we
update
our example XLS forms so that we clearly communicate the changes
across
those versions. It would also be useful if we could collectively
adopt
an
agreed-upon order of columns for all of our examples, and make
them
all
consistent, just to eliminate this point of confusion.

Mitch

On Wed, Jul 16, 2014 at 6:02 PM, Christopher Robert cro...@surveycto.com wrote:

One argument against new-columns-for-new-attributes is that it
makes
it
hard to have a single "template" that people can use for multiple
surveys.
At SurveyCTO, we early on established the norm that we'd provide
form
templates and users would fill them in -- without having to add
columns. And
then we made sure that every one of our samples used the same
template.
The
reason was this: everybody wants to copy and paste between
surveys
(more or
less all the time) and this leads to enormous difficulties when
the
set
and
order of columns isn't shared between the different surveys. We
estimate
that a large proportion of users' debugging time can easily go
into
debugging copy-paste problems that are themselves the result of
differing
column sets or orders. And that's just a terrible shame. Thus,
the
attempt
to stamp out those errors with a single template.

Now, granted, comma-delimited lists of name-value pairs is maybe
hard
for
users to construct and debug. What if we had a series of pre-set
property
columns like property-name1, property-value1, property-name2, and
so
on?
Actually, pyxform would only need to support property-name* and
property-value*, and it would be up to crazy people like us to
build
templates with a pre-fab set of them for users to fill in. But
actually, it
would also be wonderful if people could easily copy and paste
between
ODK,
formhub, Ona, Enketo, and SurveyCTO surveys... so if others
wanted
to
jump
on the "master template" idea, we could settle on a default or
example
template that has the same set and order of columns across our
different
systems. I think that everybody would benefit.

Obviously, the XML format is naturally better at supporting
ad-hoc
attributes. I'm just trying to imagine what works well in the
spreadsheet
format.

Best,

Chris

On Wed, Jul 16, 2014 at 7:16 PM, Yaw Anokwa yan...@nafundi.com wrote:

I still want there to be new columns, but we don't have to hard
code
them into pyxform.

Attributes can appear in the instance, bind, and in the body, so
my
proposal is to have three new column headers that a user can add
if
they want a new attribute. So, instance::$x, bind::$x, and
body::$x

So for the autocomplete example, that appears in the bind, so
you'd
add a column with bind::saveIncomplete. And in the row, you'd
put
true().

Then pyxform would know to generate this:

You could also then add another column with bind::myAttribute,
and
then the XML would look like:

Again, we are adding new columns to the XLS, but we don't have
to
also
add them to the pyxform code.

I think having one properties column where everything is
separated
by
commas seems more fragile and harder to debug.

On Wed, Jul 16, 2014 at 10:41 AM, Matt Berg mlb...@gmail.com wrote:

Can you elaborate with an xlsform example of how this would
work.

Instead of adding new columns we cooked add a properties
column
and
have
these be comma delimited or something like that.

On Jul 16, 2014 2:56 PM, "Yaw Anokwa" yan...@nafundi.com wrote:

Hi all,

We've added true auto save to Collect. This feature was
needed
because
we have a client who needs to save as incomplete at a
particular
point
in the form before launching an external widget.

The XML looks like this:

Before we push this code to trunk, we want to add support for
it
in
XLSForm. The obvious way to do this is to add a new column,
but
I
don't think it's sustainable in the long run for every
attribute
we
might want to add.

I wanted to bring this discussion to the community to solicit
ideas.
Is the status quo of adding a named column what we want? Or
do
we
want
a more generic solution?

For example, any column with body::x as a header would insert
x
as
an
attribute in the body XML? And bind::y would insert y as in
attribute
in the bind XML.

Good idea? Terrible idea?

Yaw

Need ODK services? http://nafundi.com provides form design,
server
setup, professional support, and software development for
ODK.

--
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.

--
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 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.

--
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/hgAXcRBkmAs/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.

--
Did you know that Enketo Smart Paper has now become the #1 tool for data
collection? Don't fall behind. Use it!

Enketo | LinkedIn | GitHub | Twitter

--
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.

[martijnr]

I'd change that, I think. If the whole form is in one fieldlist, the save
occurs when the form loads and there is no data to save? That probably
won't do what you want.

Generally for any feature like this that is attached to a particular node,
I think we should agree to use one common way. Input field focus is the
only one that make sense to me (but I understand it might performance as
the save and opening an external app would compete for OS resources).

···

On Thu, Jul 31, 2014 at 10:26 AM, Yaw Anokwa wrote:

Martijn,

I believe it does the save when the field-list finishes rendering.

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

On Tue, Jul 29, 2014 at 2:26 PM, Martijn van de Rijdt martijn@enketo.org wrote:

Are you not using the focus event yourself? If not, what is the event
that
triggers the autoSave if this question is in the middle of a field-list
of
questions that are all displayed on the same page?

On Tue, Jul 29, 2014 at 2:48 PM, Yaw Anokwa yanokwa@nafundi.com wrote:

Thanks for clarifying the select issue. I agree that it's not a blocker.

Saving when input field gets focus sounds like a nice solution for
Enketo. Or you can also ignore the tag and auto save on every change
if that's a lightweight operation for you.

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

On Tue, Jul 29, 2014 at 9:18 AM, Martijn van de Rijdt martijn@enketo.org wrote:

Hi Yaw,

I'm not clear on the select/select1 issue. Can you provide an
example?

E.g. if we want to properly add search() for external datasets to the
spec,
we could for example decide to place it in the XForm like this (on

instead of the top-level ):

(This is just a quick example. I am not proposing this way of adding
search() support).

However, this issue is not a very good reason to not have the proposed
generic body::newatttribute feature. We can use the body::newattribute
feature for development (where it's put on the element) and
if

it
gets into the spec slightly adjust it.

autoSave needs to be question specific because saving takes a long
time and so you can't save on swipe. You want the form designer to
specify when the save occurs, no? Curious why this would be
problematic for you.

The key problem for me is with any features that are triggered at a
specific
moment when a user traverses through a form. It's best illustrated by
imagining a form that is one giant field-list where everything is
displayed
on one screen (like Enketo is by default) and users that won't
necessarily
traverse the form linearly. When should the action take place? I
guess,

if
we accept the limitations of this (users skipping questions, going
back

later, changing fill-in order), we could agree on an event that works
for
all clients. Maybe this point would be when the input field gets
focus.

Is
this what you're thinking of?

Cheers,
Martijn

On Monday, July 28, 2014 2:37:59 PM UTC-6, Yaw Anokwa wrote:

Martijn,

Sounds like we have rough consensus on bind::newattribute. We'll
start

hacking away on it and submit a patch for review. My guess is that
we'll add a whitelist of standard columns and warn (but passthrough)
on any non-standard columns. We can also probably warn on if the
ordering isn't whatever we agree on.

I'm not clear on the select/select1 issue. Can you provide an
example?

autoSave needs to be question specific because saving takes a long
time and so you can't save on swipe. You want the form designer to
specify when the save occurs, no? Curious why this would be
problematic for you.

Agreed that appearance should be static. If we need parameters for
external widgets, then that seems like the bind::newattribute is the
mechanism we should use.

accuracyThreshold should be question specific. I don't feel very
strongly about it, but I can imagine situations where form specific
is

not adequate.

Yaw

On Mon, Jul 21, 2014 at 8:23 AM, Martijn van de Rijdt mar...@enketo.org wrote:

Hi,

Back from holiday. Thanks for sharing this.

Re. adding new binding attributes to XLSForm:

In my opinion, the support of bind:newattribute would be a very
worthwhile
addition to XLSForm for the purpose of allowing developers to add
client-specific features without forking XLSForm (and to facilitate
testing
new features during development while waiting for XLSForm support).
However,
for a feature that is part of the ODK XForm and XLSForm spec (and
supported
in the public ODK Collect), I think we should always add a separate
column
without the bind:: prefix. It just keeps the XLSForm format a lot
more
user-friendly and facilitates validation. (so XLSForm could ignore
and
bind::newattribute column if newattribute has its own column in the
.xls
file it's transforming).

Re. new attributes on input/select/select1/itemset elements:

Though the idea of using appearance parameters has a lot of appeal
at

first
glance, I'd like to keep appearances as simple strings without
parameters
(functioning like a style class). Anything that requires
parameter(s)

such
as accuracyThreshold should get its own column in my opinion. For
me

the
issue with allowing parameters in appearances is that appearances
should
ALWAYS be static for performance reasons and to keep form parsing
sane.
Once
you allow parameters it becomes too hard to explain why node
references
and
XPath functions are not allowed as appearance parameters but are
allowed
in
every other function in a form definition.

Adding support for body::newattribute to XLSForm (for development
or

for
client-specific features) runs into a minor difficulty of what to
do

with
select and select1 elements as the attribute may be better placed
on

an
child (e.g. a search attribute). Nevertheless, it may be
useful to
add this support and just add the attribute to select, select1 and
input
elements only.

Cheers,
Martijn

PS (not directly relevant to this general XLSForm extension
discussion):

In the case of accuracyThreshold I think it would make sense to
move

this to
the settings column to make this a form-wide setting that could
added

to
h:body in XForm.)
I may be misunderstanding the autoSave feature (which would seem a
great
addition) but if not, I have strong reservations about implementing
this
by
adding the autoSave instruction to a particular node (instead of to
the
whole form). I'll save those for a different thread if the feature
is

meant
for the the public ODK Collect. I have the same reservation for any
feature
that is dependent on a form having one question per page and
requires

a
user
to traverse a form question by question.

On Saturday, July 19, 2014 6:20:45 AM UTC-6, Yaw Anokwa wrote:

Agreed that we can at least standardize the ordering. I don't
think

it
should be strict, but a warning seems reasonable. Ditto with
attributes that aren't supported by all tools.

Martjin? Matt? You guys have been quiet. Thoughts on how we
support

attributes going forward?

Yaw

Need ODK services? http://nafundi.com provides form design,
server

setup, professional support, and software development for ODK.

On Fri, Jul 18, 2014 at 7:21 PM, Mitch Sundt <mitche...@gmail.com wrote:

Chris raises an interesting issue.

I think, however, that we want to be able to easily add columns
to

XLSForm,
and Yaw's suggestion is a good one.

We need to be able to add attributes to at least the bind
element,

and I
would argue we should allow them on the input element as well.

The odk:length, constraintMsg and requiredMsg are all on the
bind,

and
don't
make sense to attach to the input element via the appearance.
They

belong on
the bind.

For Enketo and other tools that are trying to render the forms
more
freely
and leverage the power of HTML and CSS, I would argue that the
appearance
attribute is too constraining. We should allow new attributes to
be
added to
the input element for easier extension and development of these
tools. I
could imagine wanting to define body::style on them, for
example.

And then there are things like the accuracy threshold for
geopoints.
These
aren't constraints on the value, since a location can always be
accepted
early by the user, so they should be tied to the input element,
but
they
don't affect appearance; they affect behavior. So it is awkward
to

stuff
them in the appearance attribute. Other examples might be
resolution
settings for image capture and video capture, or specifications
of

image,
audio, or video formats. But,given the external intent
launching

mechanism
that exists within the appearance attribute, and its support of
argument
lists, perhaps these behavioral settings, that are currently
separate
attributes, should be moved into the argument list of the
appearance
(e.g.,
appearance="maps(1.5)" instead of appearance="maps"
accuracyThreshold="1.5"). The downside of placing everything in
the
appearance is that you lose the readability of the XML -- you
need

to
refer
to our spec documents to know what 1.5 does, whereas having a
separate
attribute provides some self-documentation.

I don't think it is reasonable to freeze the spec and allow no
new

attributes. Several years ago, I modified the original JR
library

to
allow
new attributes specifically because it didn't allow attributes
like
odk:length on the bind.

To Chris' point, however, we might need a .NET app or other tool
that
will
unify the order and set of columns between two or more XLS
forms,

so
that
cutting-and-pasting will then work. And we should be clearer
when

we
update
our example XLS forms so that we clearly communicate the changes
across
those versions. It would also be useful if we could
collectively

adopt
an
agreed-upon order of columns for all of our examples, and make
them
all
consistent, just to eliminate this point of confusion.

Mitch

On Wed, Jul 16, 2014 at 6:02 PM, Christopher Robert cro...@surveycto.com wrote:

One argument against new-columns-for-new-attributes is that it
makes
it
hard to have a single "template" that people can use for
multiple

surveys.
At SurveyCTO, we early on established the norm that we'd
provide

form
templates and users would fill them in -- without having to add
columns. And
then we made sure that every one of our samples used the same
template.
The
reason was this: everybody wants to copy and paste between
surveys
(more or
less all the time) and this leads to enormous difficulties when
the
set
and
order of columns isn't shared between the different surveys. We
estimate
that a large proportion of users' debugging time can easily go
into
debugging copy-paste problems that are themselves the result of
differing
column sets or orders. And that's just a terrible shame. Thus,
the
attempt
to stamp out those errors with a single template.

Now, granted, comma-delimited lists of name-value pairs is
maybe

hard
for
users to construct and debug. What if we had a series of
pre-set

property
columns like property-name1, property-value1, property-name2,
and

so
on?
Actually, pyxform would only need to support property-name* and
property-value*, and it would be up to crazy people like us to
build
templates with a pre-fab set of them for users to fill in. But
actually, it
would also be wonderful if people could easily copy and paste
between
ODK,
formhub, Ona, Enketo, and SurveyCTO surveys... so if others
wanted
to
jump
on the "master template" idea, we could settle on a default or
example
template that has the same set and order of columns across our
different
systems. I think that everybody would benefit.

Obviously, the XML format is naturally better at supporting
ad-hoc
attributes. I'm just trying to imagine what works well in the
spreadsheet
format.

Best,

Chris

On Wed, Jul 16, 2014 at 7:16 PM, Yaw Anokwa < yan...@nafundi.com> wrote:

I still want there to be new columns, but we don't have to
hard

code
them into pyxform.

Attributes can appear in the instance, bind, and in the body,
so

my
proposal is to have three new column headers that a user can
add

if
they want a new attribute. So, instance::$x, bind::$x, and
body::$x

So for the autocomplete example, that appears in the bind, so
you'd
add a column with bind::saveIncomplete. And in the row, you'd
put
true().

Then pyxform would know to generate this:

You could also then add another column with bind::myAttribute,
and
then the XML would look like:

Again, we are adding new columns to the XLS, but we don't have
to
also
add them to the pyxform code.

I think having one properties column where everything is
separated
by
commas seems more fragile and harder to debug.

On Wed, Jul 16, 2014 at 10:41 AM, Matt Berg <mlb...@gmail.com wrote:

Can you elaborate with an xlsform example of how this would
work.

Instead of adding new columns we cooked add a properties
column
and
have
these be comma delimited or something like that.

On Jul 16, 2014 2:56 PM, "Yaw Anokwa" yan...@nafundi.com wrote:

Hi all,

We've added true auto save to Collect. This feature was
needed
because
we have a client who needs to save as incomplete at a
particular
point
in the form before launching an external widget.

The XML looks like this:

Before we push this code to trunk, we want to add support
for

it
in
XLSForm. The obvious way to do this is to add a new column,
but
I
don't think it's sustainable in the long run for every
attribute
we
might want to add.

I wanted to bring this discussion to the community to
solicit

ideas.
Is the status quo of adding a named column what we want? Or
do
we
want
a more generic solution?

For example, any column with body::x as a header would
insert

x
as
an
attribute in the body XML? And bind::y would insert y as in
attribute
in the bind XML.

Good idea? Terrible idea?

Yaw

Need ODK services? http://nafundi.com provides form
design,

server
setup, professional support, and software development for
ODK.

--
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.

--
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 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.

--
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/hgAXcRBkmAs/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.

--
Did you know that Enketo Smart Paper has now become the #1 tool for data
collection? Don't fall behind. Use it!

Enketo | LinkedIn | GitHub | Twitter

--
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 a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/hgAXcRBkmAs/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.

--
Did you know that Enketo Smart Paper has now become the #1 tool for data
collection? Don't fall behind. Use it!

Enketo https://enketo.org | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/MartijnR | Twitter https://twitter.com/enketo

[yanokwa]

We can't prevent all bad behavior. If the whole form is in one
fieldlist and the form saves, then that's fine. You don't lose
anything. Maybe you lose time for the save, but that's not very
harmful.

On input focus has its own set of problems. What happens if the prompt
is a read-only field? Or a multimedia field where there is no ready
input?

···

On Thu, Jul 31, 2014 at 9:43 AM, Martijn van de Rijdt wrote: > I'd change that, I think. If the whole form is in one fieldlist, the save > occurs when the form loads and there is no data to save? That probably won't > do what you want. > > Generally for any feature like this that is attached to a particular node, I > think we should agree to use one common way. Input field focus is the only > one that make sense to me (but I understand it might performance as the save > and opening an external app would compete for OS resources). > > > On Thu, Jul 31, 2014 at 10:26 AM, Yaw Anokwa wrote: >> >> Martijn, >> >> I believe it does the save when the field-list finishes rendering. >> >> Yaw >> -- >> Need ODK services? http://nafundi.com provides form design, server >> setup, professional support, and software development for ODK. >> >> On Tue, Jul 29, 2014 at 2:26 PM, Martijn van de Rijdt wrote: >> > Are you not using the focus event yourself? If not, what is the event >> > that >> > triggers the autoSave if this question is in the middle of a field-list >> > of >> > questions that are all displayed on the same page? >> > >> > >> > On Tue, Jul 29, 2014 at 2:48 PM, Yaw Anokwa wrote: >> >> >> >> Thanks for clarifying the select issue. I agree that it's not a >> >> blocker. >> >> >> >> Saving when input field gets focus sounds like a nice solution for >> >> Enketo. Or you can also ignore the tag and auto save on every change >> >> if that's a lightweight operation for you. >> >> >> >> Yaw >> >> -- >> >> Need ODK services? http://nafundi.com provides form design, server >> >> setup, professional support, and software development for ODK. >> >> >> >> On Tue, Jul 29, 2014 at 9:18 AM, Martijn van de Rijdt wrote: >> >> > Hi Yaw, >> >> > >> >> >> >> >> >> I'm not clear on the select/select1 issue. Can you provide an >> >> >> example? >> >> > >> >> > >> >> > E.g. if we want to properly add search() for external datasets to the >> >> > spec, >> >> > we could for example decide to place it in the XForm like this (on >> >> > >> >> > instead of the top-level ): >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > (This is just a quick example. I am not proposing this way of adding >> >> > search() support). >> >> > >> >> > However, this issue is not a very good reason to not have the >> >> > proposed >> >> > generic body::newatttribute feature. We can use the >> >> > body::newattribute >> >> > feature for development (where it's put on the element) and >> >> > if >> >> > it >> >> > gets into the spec slightly adjust it. >> >> > >> >> >> autoSave needs to be question specific because saving takes a long >> >> >> time and so you can't save on swipe. You want the form designer to >> >> >> specify when the save occurs, no? Curious why this would be >> >> >> problematic for you. >> >> > >> >> > >> >> > The key problem for me is with any features that are triggered at a >> >> > specific >> >> > moment when a user traverses through a form. It's best illustrated by >> >> > imagining a form that is one giant field-list where everything is >> >> > displayed >> >> > on one screen (like Enketo is by default) and users that won't >> >> > necessarily >> >> > traverse the form linearly. When should the action take place? I >> >> > guess, >> >> > if >> >> > we accept the limitations of this (users skipping questions, going >> >> > back >> >> > later, changing fill-in order), we could agree on an event that works >> >> > for >> >> > all clients. Maybe this point would be when the input field gets >> >> > focus. >> >> > Is >> >> > this what you're thinking of? >> >> > >> >> > Cheers, >> >> > Martijn >> >> > >> >> > On Monday, July 28, 2014 2:37:59 PM UTC-6, Yaw Anokwa wrote: >> >> >> >> >> >> Martijn, >> >> >> >> >> >> Sounds like we have rough consensus on bind::newattribute. We'll >> >> >> start >> >> >> hacking away on it and submit a patch for review. My guess is that >> >> >> we'll add a whitelist of standard columns and warn (but passthrough) >> >> >> on any non-standard columns. We can also probably warn on if the >> >> >> ordering isn't whatever we agree on. >> >> >> >> >> >> I'm not clear on the select/select1 issue. Can you provide an >> >> >> example? >> >> >> >> >> >> >> >> >> autoSave needs to be question specific because saving takes a long >> >> >> time and so you can't save on swipe. You want the form designer to >> >> >> specify when the save occurs, no? Curious why this would be >> >> >> problematic for you. >> >> >> >> >> >> >> >> >> Agreed that appearance should be static. If we need parameters for >> >> >> external widgets, then that seems like the bind::newattribute is the >> >> >> mechanism we should use. >> >> >> >> >> >> >> >> >> accuracyThreshold should be question specific. I don't feel very >> >> >> strongly about it, but I can imagine situations where form specific >> >> >> is >> >> >> not adequate. >> >> >> >> >> >> >> >> >> Yaw >> >> >> >> >> >> On Mon, Jul 21, 2014 at 8:23 AM, Martijn van de Rijdt wrote: >> >> >> > Hi, >> >> >> > >> >> >> > Back from holiday. Thanks for sharing this. >> >> >> > >> >> >> > Re. adding new binding attributes to XLSForm: >> >> >> > >> >> >> > In my opinion, the support of bind:newattribute would be a very >> >> >> > worthwhile >> >> >> > addition to XLSForm for the purpose of allowing developers to add >> >> >> > client-specific features without forking XLSForm (and to >> >> >> > facilitate >> >> >> > testing >> >> >> > new features during development while waiting for XLSForm >> >> >> > support). >> >> >> > However, >> >> >> > for a feature that is part of the ODK XForm and XLSForm spec (and >> >> >> > supported >> >> >> > in the public ODK Collect), I think we should always add a >> >> >> > separate >> >> >> > column >> >> >> > without the bind:: prefix. It just keeps the XLSForm format a lot >> >> >> > more >> >> >> > user-friendly and facilitates validation. (so XLSForm could ignore >> >> >> > and >> >> >> > bind::newattribute column if newattribute has its own column in >> >> >> > the >> >> >> > .xls >> >> >> > file it's transforming). >> >> >> > >> >> >> > Re. new attributes on input/select/select1/itemset elements: >> >> >> > >> >> >> > Though the idea of using appearance parameters has a lot of appeal >> >> >> > at >> >> >> > first >> >> >> > glance, I'd like to keep appearances as simple strings without >> >> >> > parameters >> >> >> > (functioning like a style class). Anything that requires >> >> >> > parameter(s) >> >> >> > such >> >> >> > as accuracyThreshold should get its own column in my opinion. For >> >> >> > me >> >> >> > the >> >> >> > issue with allowing parameters in appearances is that appearances >> >> >> > should >> >> >> > ALWAYS be static for performance reasons and to keep form parsing >> >> >> > sane. >> >> >> > Once >> >> >> > you allow parameters it becomes too hard to explain why node >> >> >> > references >> >> >> > and >> >> >> > XPath functions are not allowed as appearance parameters but are >> >> >> > allowed >> >> >> > in >> >> >> > every other function in a form definition. >> >> >> > >> >> >> > Adding support for body::newattribute to XLSForm (for development >> >> >> > or >> >> >> > for >> >> >> > client-specific features) runs into a minor difficulty of what to >> >> >> > do >> >> >> > with >> >> >> > select and select1 elements as the attribute may be better placed >> >> >> > on >> >> >> > an >> >> >> > child (e.g. a search attribute). Nevertheless, it may be >> >> >> > useful to >> >> >> > add this support and just add the attribute to select, select1 and >> >> >> > input >> >> >> > elements only. >> >> >> > >> >> >> > Cheers, >> >> >> > Martijn >> >> >> > >> >> >> > PS (not directly relevant to this general XLSForm extension >> >> >> > discussion): >> >> >> > >> >> >> > In the case of accuracyThreshold I think it would make sense to >> >> >> > move >> >> >> > this to >> >> >> > the settings column to make this a form-wide setting that could >> >> >> > added >> >> >> > to >> >> >> > h:body in XForm.) >> >> >> > I may be misunderstanding the autoSave feature (which would seem a >> >> >> > great >> >> >> > addition) but if not, I have strong reservations about >> >> >> > implementing >> >> >> > this >> >> >> > by >> >> >> > adding the autoSave instruction to a particular node (instead of >> >> >> > to >> >> >> > the >> >> >> > whole form). I'll save those for a different thread if the feature >> >> >> > is >> >> >> > meant >> >> >> > for the the public ODK Collect. I have the same reservation for >> >> >> > any >> >> >> > feature >> >> >> > that is dependent on a form having one question per page and >> >> >> > requires >> >> >> > a >> >> >> > user >> >> >> > to traverse a form question by question. >> >> >> > >> >> >> > >> >> >> > On Saturday, July 19, 2014 6:20:45 AM UTC-6, Yaw Anokwa wrote: >> >> >> >> >> >> >> >> Agreed that we can at least standardize the ordering. I don't >> >> >> >> think >> >> >> >> it >> >> >> >> should be strict, but a warning seems reasonable. Ditto with >> >> >> >> attributes that aren't supported by all tools. >> >> >> >> >> >> >> >> Martjin? Matt? You guys have been quiet. Thoughts on how we >> >> >> >> support >> >> >> >> attributes going forward? >> >> >> >> >> >> >> >> Yaw >> >> >> >> -- >> >> >> >> Need ODK services? http://nafundi.com provides form design, >> >> >> >> server >> >> >> >> setup, professional support, and software development for ODK. >> >> >> >> >> >> >> >> On Fri, Jul 18, 2014 at 7:21 PM, Mitch Sundt wrote: >> >> >> >> > Chris raises an interesting issue. >> >> >> >> > >> >> >> >> > I think, however, that we want to be able to easily add columns >> >> >> >> > to >> >> >> >> > XLSForm, >> >> >> >> > and Yaw's suggestion is a good one. >> >> >> >> > >> >> >> >> > We need to be able to add attributes to at least the bind >> >> >> >> > element, >> >> >> >> > and I >> >> >> >> > would argue we should allow them on the input element as well. >> >> >> >> > >> >> >> >> > The odk:length, constraintMsg and requiredMsg are all on the >> >> >> >> > bind, >> >> >> >> > and >> >> >> >> > don't >> >> >> >> > make sense to attach to the input element via the appearance. >> >> >> >> > They >> >> >> >> > belong on >> >> >> >> > the bind. >> >> >> >> > >> >> >> >> > For Enketo and other tools that are trying to render the forms >> >> >> >> > more >> >> >> >> > freely >> >> >> >> > and leverage the power of HTML and CSS, I would argue that the >> >> >> >> > appearance >> >> >> >> > attribute is too constraining. We should allow new attributes >> >> >> >> > to >> >> >> >> > be >> >> >> >> > added to >> >> >> >> > the input element for easier extension and development of these >> >> >> >> > tools. I >> >> >> >> > could imagine wanting to define body::style on them, for >> >> >> >> > example. >> >> >> >> > >> >> >> >> > And then there are things like the accuracy threshold for >> >> >> >> > geopoints. >> >> >> >> > These >> >> >> >> > aren't constraints on the value, since a location can always be >> >> >> >> > accepted >> >> >> >> > early by the user, so they should be tied to the input element, >> >> >> >> > but >> >> >> >> > they >> >> >> >> > don't affect appearance; they affect behavior. So it is awkward >> >> >> >> > to >> >> >> >> > stuff >> >> >> >> > them in the appearance attribute. Other examples might be >> >> >> >> > resolution >> >> >> >> > settings for image capture and video capture, or specifications >> >> >> >> > of >> >> >> >> > image, >> >> >> >> > audio, or video formats. But,given the external intent >> >> >> >> > launching >> >> >> >> > mechanism >> >> >> >> > that exists within the appearance attribute, and its support of >> >> >> >> > argument >> >> >> >> > lists, perhaps these behavioral settings, that are currently >> >> >> >> > separate >> >> >> >> > attributes, should be moved into the argument list of the >> >> >> >> > appearance >> >> >> >> > (e.g., >> >> >> >> > appearance="maps(1.5)" instead of appearance="maps" >> >> >> >> > accuracyThreshold="1.5"). The downside of placing everything >> >> >> >> > in >> >> >> >> > the >> >> >> >> > appearance is that you lose the readability of the XML -- you >> >> >> >> > need >> >> >> >> > to >> >> >> >> > refer >> >> >> >> > to our spec documents to know what 1.5 does, whereas having a >> >> >> >> > separate >> >> >> >> > attribute provides some self-documentation. >> >> >> >> > >> >> >> >> > I don't think it is reasonable to freeze the spec and allow no >> >> >> >> > new >> >> >> >> > attributes. Several years ago, I modified the original JR >> >> >> >> > library >> >> >> >> > to >> >> >> >> > allow >> >> >> >> > new attributes specifically because it didn't allow attributes >> >> >> >> > like >> >> >> >> > odk:length on the bind. >> >> >> >> > >> >> >> >> > To Chris' point, however, we might need a .NET app or other >> >> >> >> > tool >> >> >> >> > that >> >> >> >> > will >> >> >> >> > unify the order and set of columns between two or more XLS >> >> >> >> > forms, >> >> >> >> > so >> >> >> >> > that >> >> >> >> > cutting-and-pasting will then work. And we should be clearer >> >> >> >> > when >> >> >> >> > we >> >> >> >> > update >> >> >> >> > our example XLS forms so that we clearly communicate the >> >> >> >> > changes >> >> >> >> > across >> >> >> >> > those versions. It would also be useful if we could >> >> >> >> > collectively >> >> >> >> > adopt >> >> >> >> > an >> >> >> >> > agreed-upon order of columns for all of our examples, and make >> >> >> >> > them >> >> >> >> > all >> >> >> >> > consistent, just to eliminate this point of confusion. >> >> >> >> > >> >> >> >> > Mitch >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > On Wed, Jul 16, 2014 at 6:02 PM, Christopher Robert wrote: >> >> >> >> >> >> >> >> >> >> One argument against new-columns-for-new-attributes is that it >> >> >> >> >> makes >> >> >> >> >> it >> >> >> >> >> hard to have a single "template" that people can use for >> >> >> >> >> multiple >> >> >> >> >> surveys. >> >> >> >> >> At SurveyCTO, we early on established the norm that we'd >> >> >> >> >> provide >> >> >> >> >> form >> >> >> >> >> templates and users would fill them in -- without having to >> >> >> >> >> add >> >> >> >> >> columns. And >> >> >> >> >> then we made sure that every one of our samples used the same >> >> >> >> >> template. >> >> >> >> >> The >> >> >> >> >> reason was this: everybody wants to copy and paste between >> >> >> >> >> surveys >> >> >> >> >> (more or >> >> >> >> >> less all the time) and this leads to enormous difficulties >> >> >> >> >> when >> >> >> >> >> the >> >> >> >> >> set >> >> >> >> >> and >> >> >> >> >> order of columns isn't shared between the different surveys. >> >> >> >> >> We >> >> >> >> >> estimate >> >> >> >> >> that a large proportion of users' debugging time can easily go >> >> >> >> >> into >> >> >> >> >> debugging copy-paste problems that are themselves the result >> >> >> >> >> of >> >> >> >> >> differing >> >> >> >> >> column sets or orders. And that's just a terrible shame. Thus, >> >> >> >> >> the >> >> >> >> >> attempt >> >> >> >> >> to stamp out those errors with a single template. >> >> >> >> >> >> >> >> >> >> Now, granted, comma-delimited lists of name-value pairs is >> >> >> >> >> maybe >> >> >> >> >> hard >> >> >> >> >> for >> >> >> >> >> users to construct and debug. What if we had a series of >> >> >> >> >> pre-set >> >> >> >> >> property >> >> >> >> >> columns like property-name1, property-value1, property-name2, >> >> >> >> >> and >> >> >> >> >> so >> >> >> >> >> on? >> >> >> >> >> Actually, pyxform would only need to support property-name* >> >> >> >> >> and >> >> >> >> >> property-value*, and it would be up to crazy people like us to >> >> >> >> >> build >> >> >> >> >> templates with a pre-fab set of them for users to fill in. But >> >> >> >> >> actually, it >> >> >> >> >> would also be wonderful if people could easily copy and paste >> >> >> >> >> between >> >> >> >> >> ODK, >> >> >> >> >> formhub, Ona, Enketo, and SurveyCTO surveys... so if others >> >> >> >> >> wanted >> >> >> >> >> to >> >> >> >> >> jump >> >> >> >> >> on the "master template" idea, we could settle on a default or >> >> >> >> >> example >> >> >> >> >> template that has the same set and order of columns across our >> >> >> >> >> different >> >> >> >> >> systems. I think that everybody would benefit. >> >> >> >> >> >> >> >> >> >> Obviously, the XML format is naturally better at supporting >> >> >> >> >> ad-hoc >> >> >> >> >> attributes. I'm just trying to imagine what works well in the >> >> >> >> >> spreadsheet >> >> >> >> >> format. >> >> >> >> >> >> >> >> >> >> Best, >> >> >> >> >> >> >> >> >> >> Chris >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Jul 16, 2014 at 7:16 PM, Yaw Anokwa wrote: >> >> >> >> >>> >> >> >> >> >>> I still want there to be new columns, but we don't have to >> >> >> >> >>> hard >> >> >> >> >>> code >> >> >> >> >>> them into pyxform. >> >> >> >> >>> >> >> >> >> >>> Attributes can appear in the instance, bind, and in the body, >> >> >> >> >>> so >> >> >> >> >>> my >> >> >> >> >>> proposal is to have three new column headers that a user can >> >> >> >> >>> add >> >> >> >> >>> if >> >> >> >> >>> they want a new attribute. So, instance::$x, bind::$x, and >> >> >> >> >>> body::$x >> >> >> >> >>> >> >> >> >> >>> So for the autocomplete example, that appears in the bind, so >> >> >> >> >>> you'd >> >> >> >> >>> add a column with bind::saveIncomplete. And in the row, you'd >> >> >> >> >>> put >> >> >> >> >>> true(). >> >> >> >> >>> >> >> >> >> >>> Then pyxform would know to generate this: >> >> >> >> >>> > >> >> >> >>> saveIncomplete="true()" >> >> >> >> >>> /> >> >> >> >> >>> >> >> >> >> >>> You could also then add another column with >> >> >> >> >>> bind::myAttribute, >> >> >> >> >>> and >> >> >> >> >>> then the XML would look like: >> >> >> >> >>> > >> >> >> >>> saveIncomplete="true()" >> >> >> >> >>> myAttribute="whatever" /> >> >> >> >> >>> >> >> >> >> >>> Again, we are adding new columns to the XLS, but we don't >> >> >> >> >>> have >> >> >> >> >>> to >> >> >> >> >>> also >> >> >> >> >>> add them to the pyxform code. >> >> >> >> >>> >> >> >> >> >>> I think having one properties column where everything is >> >> >> >> >>> separated >> >> >> >> >>> by >> >> >> >> >>> commas seems more fragile and harder to debug. >> >> >> >> >>> >> >> >> >> >>> On Wed, Jul 16, 2014 at 10:41 AM, Matt Berg wrote: >> >> >> >> >>> > Can you elaborate with an xlsform example of how this would >> >> >> >> >>> > work. >> >> >> >> >>> > >> >> >> >> >>> > Instead of adding new columns we cooked add a properties >> >> >> >> >>> > column >> >> >> >> >>> > and >> >> >> >> >>> > have >> >> >> >> >>> > these be comma delimited or something like that. >> >> >> >> >>> > >> >> >> >> >>> > On Jul 16, 2014 2:56 PM, "Yaw Anokwa" wrote: >> >> >> >> >>> >> >> >> >> >> >>> >> Hi all, >> >> >> >> >>> >> >> >> >> >> >>> >> We've added true auto save to Collect. This feature was >> >> >> >> >>> >> needed >> >> >> >> >>> >> because >> >> >> >> >>> >> we have a client who needs to save as incomplete at a >> >> >> >> >>> >> particular >> >> >> >> >>> >> point >> >> >> >> >>> >> in the form before launching an external widget. >> >> >> >> >>> >> >> >> >> >> >>> >> The XML looks like this: >> >> >> >> >>> >> > >> >> >> >>> >> saveIncomplete="true()" >> >> >> >> >>> >> /> >> >> >> >> >>> >> >> >> >> >> >>> >> Before we push this code to trunk, we want to add support >> >> >> >> >>> >> for >> >> >> >> >>> >> it >> >> >> >> >>> >> in >> >> >> >> >>> >> XLSForm. The obvious way to do this is to add a new >> >> >> >> >>> >> column, >> >> >> >> >>> >> but >> >> >> >> >>> >> I >> >> >> >> >>> >> don't think it's sustainable in the long run for every >> >> >> >> >>> >> attribute >> >> >> >> >>> >> we >> >> >> >> >>> >> might want to add. >> >> >> >> >>> >> >> >> >> >> >>> >> I wanted to bring this discussion to the community to >> >> >> >> >>> >> solicit >> >> >> >> >>> >> ideas. >> >> >> >> >>> >> Is the status quo of adding a named column what we want? >> >> >> >> >>> >> Or >> >> >> >> >>> >> do >> >> >> >> >>> >> we >> >> >> >> >>> >> want >> >> >> >> >>> >> a more generic solution? >> >> >> >> >>> >> >> >> >> >> >>> >> For example, any column with body::x as a header would >> >> >> >> >>> >> insert >> >> >> >> >>> >> x >> >> >> >> >>> >> as >> >> >> >> >>> >> an >> >> >> >> >>> >> attribute in the body XML? And bind::y would insert y as >> >> >> >> >>> >> in >> >> >> >> >>> >> attribute >> >> >> >> >>> >> in the bind XML. >> >> >> >> >>> >> >> >> >> >> >>> >> Good idea? Terrible idea? >> >> >> >> >>> >> >> >> >> >> >>> >> Yaw >> >> >> >> >>> >> -- >> >> >> >> >>> >> Need ODK services? http://nafundi.com provides form >> >> >> >> >>> >> design, >> >> >> >> >>> >> server >> >> >> >> >>> >> setup, professional support, and software development for >> >> >> >> >>> >> ODK. >> >> >> >> >>> >> >> >> >> >> >>> >> -- >> >> >> >> >>> >> 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. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> 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 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. >> >> >> >> -- >> >> 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/hgAXcRBkmAs/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. >> > >> > >> > >> > >> > -- >> > Did you know that Enketo Smart Paper has now become the #1 tool for data >> > collection? Don't fall behind. Use it! >> > >> > Enketo | LinkedIn | GitHub | Twitter >> > >> > -- >> > 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 a topic in the >> Google Groups "ODK Developers" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/opendatakit-developers/hgAXcRBkmAs/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. > > > > > -- > Did you know that Enketo Smart Paper has now become the #1 tool for data > collection? Don't fall behind. Use it! > > Enketo | LinkedIn | GitHub | Twitter > > -- > 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.

[martijnr]

Yes, true about readonly fields (not sure what you mean with multimedia
field not having a ready input).

I wish we could find a solid common way to trigger these node-bound actions
though. Maybe . I'm thinking about other features we might want to
add in the future, like auditing.

···

On Mon, Aug 4, 2014 at 6:06 PM, Yaw Anokwa wrote:

We can't prevent all bad behavior. If the whole form is in one
fieldlist and the form saves, then that's fine. You don't lose
anything. Maybe you lose time for the save, but that's not very
harmful.

On input focus has its own set of problems. What happens if the prompt
is a read-only field? Or a multimedia field where there is no ready
input?

On Thu, Jul 31, 2014 at 9:43 AM, Martijn van de Rijdt martijn@enketo.org wrote:

I'd change that, I think. If the whole form is in one fieldlist, the save
occurs when the form loads and there is no data to save? That probably
won't
do what you want.

Generally for any feature like this that is attached to a particular
node, I
think we should agree to use one common way. Input field focus is the
only
one that make sense to me (but I understand it might performance as the
save
and opening an external app would compete for OS resources).

On Thu, Jul 31, 2014 at 10:26 AM, Yaw Anokwa yanokwa@nafundi.com wrote:

Martijn,

I believe it does the save when the field-list finishes rendering.

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

On Tue, Jul 29, 2014 at 2:26 PM, Martijn van de Rijdt martijn@enketo.org wrote:

Are you not using the focus event yourself? If not, what is the event
that
triggers the autoSave if this question is in the middle of a
field-list

of
questions that are all displayed on the same page?

On Tue, Jul 29, 2014 at 2:48 PM, Yaw Anokwa yanokwa@nafundi.com wrote:

Thanks for clarifying the select issue. I agree that it's not a
blocker.

Saving when input field gets focus sounds like a nice solution for
Enketo. Or you can also ignore the tag and auto save on every change
if that's a lightweight operation for you.

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

On Tue, Jul 29, 2014 at 9:18 AM, Martijn van de Rijdt martijn@enketo.org wrote:

Hi Yaw,

I'm not clear on the select/select1 issue. Can you provide an
example?

E.g. if we want to properly add search() for external datasets to
the

spec,
we could for example decide to place it in the XForm like this (on

instead of the top-level ):

(This is just a quick example. I am not proposing this way of
adding

search() support).

However, this issue is not a very good reason to not have the
proposed
generic body::newatttribute feature. We can use the
body::newattribute
feature for development (where it's put on the element)
and

if
it
gets into the spec slightly adjust it.

autoSave needs to be question specific because saving takes a long
time and so you can't save on swipe. You want the form designer to
specify when the save occurs, no? Curious why this would be
problematic for you.

The key problem for me is with any features that are triggered at a
specific
moment when a user traverses through a form. It's best illustrated
by

imagining a form that is one giant field-list where everything is
displayed
on one screen (like Enketo is by default) and users that won't
necessarily
traverse the form linearly. When should the action take place? I
guess,
if
we accept the limitations of this (users skipping questions, going
back
later, changing fill-in order), we could agree on an event that
works

for
all clients. Maybe this point would be when the input field gets
focus.
Is
this what you're thinking of?

Cheers,
Martijn

On Monday, July 28, 2014 2:37:59 PM UTC-6, Yaw Anokwa wrote:

Martijn,

Sounds like we have rough consensus on bind::newattribute. We'll
start
hacking away on it and submit a patch for review. My guess is that
we'll add a whitelist of standard columns and warn (but
passthrough)

on any non-standard columns. We can also probably warn on if the
ordering isn't whatever we agree on.

I'm not clear on the select/select1 issue. Can you provide an
example?

autoSave needs to be question specific because saving takes a long
time and so you can't save on swipe. You want the form designer to
specify when the save occurs, no? Curious why this would be
problematic for you.

Agreed that appearance should be static. If we need parameters for
external widgets, then that seems like the bind::newattribute is
the

mechanism we should use.

accuracyThreshold should be question specific. I don't feel very
strongly about it, but I can imagine situations where form
specific

is
not adequate.

Yaw

On Mon, Jul 21, 2014 at 8:23 AM, Martijn van de Rijdt mar...@enketo.org wrote:

Hi,

Back from holiday. Thanks for sharing this.

Re. adding new binding attributes to XLSForm:

In my opinion, the support of bind:newattribute would be a very
worthwhile
addition to XLSForm for the purpose of allowing developers to
add

client-specific features without forking XLSForm (and to
facilitate
testing
new features during development while waiting for XLSForm
support).
However,
for a feature that is part of the ODK XForm and XLSForm spec
(and

supported
in the public ODK Collect), I think we should always add a
separate
column
without the bind:: prefix. It just keeps the XLSForm format a
lot

more
user-friendly and facilitates validation. (so XLSForm could
ignore

and
bind::newattribute column if newattribute has its own column in
the
.xls
file it's transforming).

Re. new attributes on input/select/select1/itemset elements:

Though the idea of using appearance parameters has a lot of
appeal

at
first
glance, I'd like to keep appearances as simple strings without
parameters
(functioning like a style class). Anything that requires
parameter(s)
such
as accuracyThreshold should get its own column in my opinion.
For

me
the
issue with allowing parameters in appearances is that
appearances

should
ALWAYS be static for performance reasons and to keep form
parsing

sane.
Once
you allow parameters it becomes too hard to explain why node
references
and
XPath functions are not allowed as appearance parameters but are
allowed
in
every other function in a form definition.

Adding support for body::newattribute to XLSForm (for
development

or
for
client-specific features) runs into a minor difficulty of what
to

do
with
select and select1 elements as the attribute may be better
placed

on
an
child (e.g. a search attribute). Nevertheless, it may
be

useful to
add this support and just add the attribute to select, select1
and

input
elements only.

Cheers,
Martijn

PS (not directly relevant to this general XLSForm extension
discussion):

In the case of accuracyThreshold I think it would make sense to
move
this to
the settings column to make this a form-wide setting that could
added
to
h:body in XForm.)
I may be misunderstanding the autoSave feature (which would
seem a

great
addition) but if not, I have strong reservations about
implementing
this
by
adding the autoSave instruction to a particular node (instead of
to
the
whole form). I'll save those for a different thread if the
feature

is
meant
for the the public ODK Collect. I have the same reservation for
any
feature
that is dependent on a form having one question per page and
requires
a
user
to traverse a form question by question.

On Saturday, July 19, 2014 6:20:45 AM UTC-6, Yaw Anokwa wrote:

Agreed that we can at least standardize the ordering. I don't
think
it
should be strict, but a warning seems reasonable. Ditto with
attributes that aren't supported by all tools.

Martjin? Matt? You guys have been quiet. Thoughts on how we
support
attributes going forward?

Yaw

Need ODK services? http://nafundi.com provides form design,
server
setup, professional support, and software development for ODK.

On Fri, Jul 18, 2014 at 7:21 PM, Mitch Sundt mitche...@gmail.com wrote:

Chris raises an interesting issue.

I think, however, that we want to be able to easily add
columns

to
XLSForm,
and Yaw's suggestion is a good one.

We need to be able to add attributes to at least the bind
element,
and I
would argue we should allow them on the input element as
well.

The odk:length, constraintMsg and requiredMsg are all on the
bind,
and
don't
make sense to attach to the input element via the appearance.
They
belong on
the bind.

For Enketo and other tools that are trying to render the
forms

more
freely
and leverage the power of HTML and CSS, I would argue that
the

appearance
attribute is too constraining. We should allow new attributes
to
be
added to
the input element for easier extension and development of
these

tools. I
could imagine wanting to define body::style on them, for
example.

And then there are things like the accuracy threshold for
geopoints.
These
aren't constraints on the value, since a location can always
be

accepted
early by the user, so they should be tied to the input
element,

but
they
don't affect appearance; they affect behavior. So it is
awkward

to
stuff
them in the appearance attribute. Other examples might be
resolution
settings for image capture and video capture, or
specifications

of
image,
audio, or video formats. But,given the external intent
launching
mechanism
that exists within the appearance attribute, and its support
of

argument
lists, perhaps these behavioral settings, that are currently
separate
attributes, should be moved into the argument list of the
appearance
(e.g.,
appearance="maps(1.5)" instead of appearance="maps"
accuracyThreshold="1.5"). The downside of placing everything
in
the
appearance is that you lose the readability of the XML -- you
need
to
refer
to our spec documents to know what 1.5 does, whereas having a
separate
attribute provides some self-documentation.

I don't think it is reasonable to freeze the spec and allow
no

new
attributes. Several years ago, I modified the original JR
library
to
allow
new attributes specifically because it didn't allow
attributes

like
odk:length on the bind.

To Chris' point, however, we might need a .NET app or other
tool
that
will
unify the order and set of columns between two or more XLS
forms,
so
that
cutting-and-pasting will then work. And we should be clearer
when
we
update
our example XLS forms so that we clearly communicate the
changes
across
those versions. It would also be useful if we could
collectively
adopt
an
agreed-upon order of columns for all of our examples, and
make

them
all
consistent, just to eliminate this point of confusion.

Mitch

On Wed, Jul 16, 2014 at 6:02 PM, Christopher Robert cro...@surveycto.com wrote:

One argument against new-columns-for-new-attributes is that
it

makes
it
hard to have a single "template" that people can use for
multiple
surveys.
At SurveyCTO, we early on established the norm that we'd
provide
form
templates and users would fill them in -- without having to
add
columns. And
then we made sure that every one of our samples used the
same

template.
The
reason was this: everybody wants to copy and paste between
surveys
(more or
less all the time) and this leads to enormous difficulties
when
the
set
and
order of columns isn't shared between the different surveys.
We
estimate
that a large proportion of users' debugging time can easily
go

into
debugging copy-paste problems that are themselves the result
of
differing
column sets or orders. And that's just a terrible shame.
Thus,

the
attempt
to stamp out those errors with a single template.

Now, granted, comma-delimited lists of name-value pairs is
maybe
hard
for
users to construct and debug. What if we had a series of
pre-set
property
columns like property-name1, property-value1,
property-name2,

and
so
on?
Actually, pyxform would only need to support property-name*
and
property-value*, and it would be up to crazy people like us
to

build
templates with a pre-fab set of them for users to fill in.
But

actually, it
would also be wonderful if people could easily copy and
paste

between
ODK,
formhub, Ona, Enketo, and SurveyCTO surveys... so if others
wanted
to
jump
on the "master template" idea, we could settle on a default
or

example
template that has the same set and order of columns across
our

different
systems. I think that everybody would benefit.

Obviously, the XML format is naturally better at supporting
ad-hoc
attributes. I'm just trying to imagine what works well in
the

spreadsheet
format.

Best,

Chris

On Wed, Jul 16, 2014 at 7:16 PM, Yaw Anokwa yan...@nafundi.com wrote:

I still want there to be new columns, but we don't have to
hard
code
them into pyxform.

Attributes can appear in the instance, bind, and in the
body,

so
my
proposal is to have three new column headers that a user
can

add
if
they want a new attribute. So, instance::$x, bind::$x, and
body::$x

So for the autocomplete example, that appears in the bind,
so

you'd
add a column with bind::saveIncomplete. And in the row,
you'd

put
true().

Then pyxform would know to generate this:

You could also then add another column with
bind::myAttribute,
and
then the XML would look like:

Again, we are adding new columns to the XLS, but we don't
have
to
also
add them to the pyxform code.

I think having one properties column where everything is
separated
by
commas seems more fragile and harder to debug.

On Wed, Jul 16, 2014 at 10:41 AM, Matt Berg mlb...@gmail.com wrote:

Can you elaborate with an xlsform example of how this
would

work.

Instead of adding new columns we cooked add a properties
column
and
have
these be comma delimited or something like that.

On Jul 16, 2014 2:56 PM, "Yaw Anokwa" < yan...@nafundi.com> wrote:

Hi all,

We've added true auto save to Collect. This feature was
needed
because
we have a client who needs to save as incomplete at a
particular
point
in the form before launching an external widget.

The XML looks like this:

Before we push this code to trunk, we want to add
support

for
it
in
XLSForm. The obvious way to do this is to add a new
column,
but
I
don't think it's sustainable in the long run for every
attribute
we
might want to add.

I wanted to bring this discussion to the community to
solicit
ideas.
Is the status quo of adding a named column what we want?
Or
do
we
want
a more generic solution?

For example, any column with body::x as a header would
insert
x
as
an
attribute in the body XML? And bind::y would insert y as
in
attribute
in the bind XML.

Good idea? Terrible idea?

Yaw

Need ODK services? http://nafundi.com provides form
design,
server
setup, professional support, and software development
for

ODK.

--
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
.

--
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 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.

--
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/hgAXcRBkmAs/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.

--
Did you know that Enketo Smart Paper has now become the #1 tool for
data

collection? Don't fall behind. Use it!

Enketo | LinkedIn | GitHub | Twitter

--
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 a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit

https://groups.google.com/d/topic/opendatakit-developers/hgAXcRBkmAs/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.

--
Did you know that Enketo Smart Paper has now become the #1 tool for data
collection? Don't fall behind. Use it!

Enketo | LinkedIn | GitHub | Twitter

--
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 a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/hgAXcRBkmAs/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.

--
Did you know that Enketo Smart Paper has now become the #1 tool for data
collection? Don't fall behind. Use it!

Enketo https://enketo.org | LinkedIn
http://www.linkedin.com/company/enketo-llc | GitHub
https://github.com/MartijnR | Twitter https://twitter.com/enketo

[yanokwa]

Just circling back on this...

We've submitted a pull request for this feature in pyxform:
https://github.com/SEL-Columbia/pyxform/pull/121

We've also pushed saveIncomplete to ODK Collect:
https://code.google.com/p/opendatakit/source/detail?r=ca06fc5e05969399dc684fca69a1ae5710ac2db1&repo=collect

Please try it out and offer your feedback.

Yaw

···

-- Need ODK services? http://nafundi.com provides form design, server setup, professional support, and software development for ODK.

On Tue, Aug 5, 2014 at 7:58 AM, Martijn van de Rijdt martijn@enketo.org wrote:

Yes, true about readonly fields (not sure what you mean with multimedia
field not having a ready input).

I wish we could find a solid common way to trigger these node-bound actions
though. Maybe . I'm thinking about other features we might want to
add in the future, like auditing.

On Mon, Aug 4, 2014 at 6:06 PM, Yaw Anokwa yanokwa@nafundi.com wrote:

We can't prevent all bad behavior. If the whole form is in one
fieldlist and the form saves, then that's fine. You don't lose
anything. Maybe you lose time for the save, but that's not very
harmful.

On input focus has its own set of problems. What happens if the prompt
is a read-only field? Or a multimedia field where there is no ready
input?

On Thu, Jul 31, 2014 at 9:43 AM, Martijn van de Rijdt martijn@enketo.org wrote:

I'd change that, I think. If the whole form is in one fieldlist, the
save
occurs when the form loads and there is no data to save? That probably
won't
do what you want.

Generally for any feature like this that is attached to a particular
node, I
think we should agree to use one common way. Input field focus is the
only
one that make sense to me (but I understand it might performance as the
save
and opening an external app would compete for OS resources).

On Thu, Jul 31, 2014 at 10:26 AM, Yaw Anokwa yanokwa@nafundi.com wrote:

Martijn,

I believe it does the save when the field-list finishes rendering.

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

On Tue, Jul 29, 2014 at 2:26 PM, Martijn van de Rijdt martijn@enketo.org wrote:

Are you not using the focus event yourself? If not, what is the event
that
triggers the autoSave if this question is in the middle of a
field-list
of
questions that are all displayed on the same page?

On Tue, Jul 29, 2014 at 2:48 PM, Yaw Anokwa yanokwa@nafundi.com wrote:

Thanks for clarifying the select issue. I agree that it's not a
blocker.

Saving when input field gets focus sounds like a nice solution for
Enketo. Or you can also ignore the tag and auto save on every change
if that's a lightweight operation for you.

Yaw

Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.

On Tue, Jul 29, 2014 at 9:18 AM, Martijn van de Rijdt martijn@enketo.org wrote:

Hi Yaw,

I'm not clear on the select/select1 issue. Can you provide an
example?

E.g. if we want to properly add search() for external datasets to
the
spec,
we could for example decide to place it in the XForm like this (on

instead of the top-level ):

(This is just a quick example. I am not proposing this way of
adding
search() support).

However, this issue is not a very good reason to not have the
proposed
generic body::newatttribute feature. We can use the
body::newattribute
feature for development (where it's put on the element)
and
if
it
gets into the spec slightly adjust it.

autoSave needs to be question specific because saving takes a
long
time and so you can't save on swipe. You want the form designer
to
specify when the save occurs, no? Curious why this would be
problematic for you.

The key problem for me is with any features that are triggered at
a
specific
moment when a user traverses through a form. It's best illustrated
by
imagining a form that is one giant field-list where everything is
displayed
on one screen (like Enketo is by default) and users that won't
necessarily
traverse the form linearly. When should the action take place? I
guess,
if
we accept the limitations of this (users skipping questions, going
back
later, changing fill-in order), we could agree on an event that
works
for
all clients. Maybe this point would be when the input field gets
focus.
Is
this what you're thinking of?

Cheers,
Martijn

On Monday, July 28, 2014 2:37:59 PM UTC-6, Yaw Anokwa wrote:

Martijn,

Sounds like we have rough consensus on bind::newattribute. We'll
start
hacking away on it and submit a patch for review. My guess is
that
we'll add a whitelist of standard columns and warn (but
passthrough)
on any non-standard columns. We can also probably warn on if the
ordering isn't whatever we agree on.

I'm not clear on the select/select1 issue. Can you provide an
example?

autoSave needs to be question specific because saving takes a
long
time and so you can't save on swipe. You want the form designer
to
specify when the save occurs, no? Curious why this would be
problematic for you.

Agreed that appearance should be static. If we need parameters
for
external widgets, then that seems like the bind::newattribute is
the
mechanism we should use.

accuracyThreshold should be question specific. I don't feel very
strongly about it, but I can imagine situations where form
specific
is
not adequate.

Yaw

On Mon, Jul 21, 2014 at 8:23 AM, Martijn van de Rijdt mar...@enketo.org wrote:

Hi,

Back from holiday. Thanks for sharing this.

Re. adding new binding attributes to XLSForm:

In my opinion, the support of bind:newattribute would be a very
worthwhile
addition to XLSForm for the purpose of allowing developers to
add
client-specific features without forking XLSForm (and to
facilitate
testing
new features during development while waiting for XLSForm
support).
However,
for a feature that is part of the ODK XForm and XLSForm spec
(and
supported
in the public ODK Collect), I think we should always add a
separate
column
without the bind:: prefix. It just keeps the XLSForm format a
lot
more
user-friendly and facilitates validation. (so XLSForm could
ignore
and
bind::newattribute column if newattribute has its own column in
the
.xls
file it's transforming).

Re. new attributes on input/select/select1/itemset elements:

Though the idea of using appearance parameters has a lot of
appeal
at
first
glance, I'd like to keep appearances as simple strings without
parameters
(functioning like a style class). Anything that requires
parameter(s)
such
as accuracyThreshold should get its own column in my opinion.
For
me
the
issue with allowing parameters in appearances is that
appearances
should
ALWAYS be static for performance reasons and to keep form
parsing
sane.
Once
you allow parameters it becomes too hard to explain why node
references
and
XPath functions are not allowed as appearance parameters but
are
allowed
in
every other function in a form definition.

Adding support for body::newattribute to XLSForm (for
development
or
for
client-specific features) runs into a minor difficulty of what
to
do
with
select and select1 elements as the attribute may be better
placed
on
an
child (e.g. a search attribute). Nevertheless, it may
be
useful to
add this support and just add the attribute to select, select1
and
input
elements only.

Cheers,
Martijn

PS (not directly relevant to this general XLSForm extension
discussion):

In the case of accuracyThreshold I think it would make sense to
move
this to
the settings column to make this a form-wide setting that could
added
to
h:body in XForm.)
I may be misunderstanding the autoSave feature (which would
seem a
great
addition) but if not, I have strong reservations about
implementing
this
by
adding the autoSave instruction to a particular node (instead
of
to
the
whole form). I'll save those for a different thread if the
feature
is
meant
for the the public ODK Collect. I have the same reservation for
any
feature
that is dependent on a form having one question per page and
requires
a
user
to traverse a form question by question.

On Saturday, July 19, 2014 6:20:45 AM UTC-6, Yaw Anokwa wrote:

Agreed that we can at least standardize the ordering. I don't
think
it
should be strict, but a warning seems reasonable. Ditto with
attributes that aren't supported by all tools.

Martjin? Matt? You guys have been quiet. Thoughts on how we
support
attributes going forward?

Yaw

Need ODK services? http://nafundi.com provides form design,
server
setup, professional support, and software development for ODK.

On Fri, Jul 18, 2014 at 7:21 PM, Mitch Sundt mitche...@gmail.com wrote:

Chris raises an interesting issue.

I think, however, that we want to be able to easily add
columns
to
XLSForm,
and Yaw's suggestion is a good one.

We need to be able to add attributes to at least the bind
element,
and I
would argue we should allow them on the input element as
well.

The odk:length, constraintMsg and requiredMsg are all on the
bind,
and
don't
make sense to attach to the input element via the
appearance.
They
belong on
the bind.

For Enketo and other tools that are trying to render the
forms
more
freely
and leverage the power of HTML and CSS, I would argue that
the
appearance
attribute is too constraining. We should allow new
attributes
to
be
added to
the input element for easier extension and development of
these
tools. I
could imagine wanting to define body::style on them, for
example.

And then there are things like the accuracy threshold for
geopoints.
These
aren't constraints on the value, since a location can always
be
accepted
early by the user, so they should be tied to the input
element,
but
they
don't affect appearance; they affect behavior. So it is
awkward
to
stuff
them in the appearance attribute. Other examples might be
resolution
settings for image capture and video capture, or
specifications
of
image,
audio, or video formats. But,given the external intent
launching
mechanism
that exists within the appearance attribute, and its support
of
argument
lists, perhaps these behavioral settings, that are currently
separate
attributes, should be moved into the argument list of the
appearance
(e.g.,
appearance="maps(1.5)" instead of appearance="maps"
accuracyThreshold="1.5"). The downside of placing
everything
in
the
appearance is that you lose the readability of the XML --
you
need
to
refer
to our spec documents to know what 1.5 does, whereas having
a
separate
attribute provides some self-documentation.

I don't think it is reasonable to freeze the spec and allow
no
new
attributes. Several years ago, I modified the original JR
library
to
allow
new attributes specifically because it didn't allow
attributes
like
odk:length on the bind.

To Chris' point, however, we might need a .NET app or other
tool
that
will
unify the order and set of columns between two or more XLS
forms,
so
that
cutting-and-pasting will then work. And we should be clearer
when
we
update
our example XLS forms so that we clearly communicate the
changes
across
those versions. It would also be useful if we could
collectively
adopt
an
agreed-upon order of columns for all of our examples, and
make
them
all
consistent, just to eliminate this point of confusion.

Mitch

On Wed, Jul 16, 2014 at 6:02 PM, Christopher Robert cro...@surveycto.com wrote:

One argument against new-columns-for-new-attributes is that
it
makes
it
hard to have a single "template" that people can use for
multiple
surveys.
At SurveyCTO, we early on established the norm that we'd
provide
form
templates and users would fill them in -- without having to
add
columns. And
then we made sure that every one of our samples used the
same
template.
The
reason was this: everybody wants to copy and paste between
surveys
(more or
less all the time) and this leads to enormous difficulties
when
the
set
and
order of columns isn't shared between the different
surveys.
We
estimate
that a large proportion of users' debugging time can easily
go
into
debugging copy-paste problems that are themselves the
result
of
differing
column sets or orders. And that's just a terrible shame.
Thus,
the
attempt
to stamp out those errors with a single template.

Now, granted, comma-delimited lists of name-value pairs is
maybe
hard
for
users to construct and debug. What if we had a series of
pre-set
property
columns like property-name1, property-value1,
property-name2,
and
so
on?
Actually, pyxform would only need to support property-name*
and
property-value*, and it would be up to crazy people like us
to
build
templates with a pre-fab set of them for users to fill in.
But
actually, it
would also be wonderful if people could easily copy and
paste
between
ODK,
formhub, Ona, Enketo, and SurveyCTO surveys... so if others
wanted
to
jump
on the "master template" idea, we could settle on a default
or
example
template that has the same set and order of columns across
our
different
systems. I think that everybody would benefit.

Obviously, the XML format is naturally better at supporting
ad-hoc
attributes. I'm just trying to imagine what works well in
the
spreadsheet
format.

Best,

Chris

On Wed, Jul 16, 2014 at 7:16 PM, Yaw Anokwa yan...@nafundi.com wrote:

I still want there to be new columns, but we don't have to
hard
code
them into pyxform.

Attributes can appear in the instance, bind, and in the
body,
so
my
proposal is to have three new column headers that a user
can
add
if
they want a new attribute. So, instance::$x, bind::$x, and
body::$x

So for the autocomplete example, that appears in the bind,
so
you'd
add a column with bind::saveIncomplete. And in the row,
you'd
put
true().

Then pyxform would know to generate this:

You could also then add another column with
bind::myAttribute,
and
then the XML would look like:

Again, we are adding new columns to the XLS, but we don't
have
to
also
add them to the pyxform code.

I think having one properties column where everything is
separated
by
commas seems more fragile and harder to debug.

On Wed, Jul 16, 2014 at 10:41 AM, Matt Berg mlb...@gmail.com wrote:

Can you elaborate with an xlsform example of how this
would
work.

Instead of adding new columns we cooked add a properties
column
and
have
these be comma delimited or something like that.

On Jul 16, 2014 2:56 PM, "Yaw Anokwa" yan...@nafundi.com wrote:

Hi all,

We've added true auto save to Collect. This feature was
needed
because
we have a client who needs to save as incomplete at a
particular
point
in the form before launching an external widget.

The XML looks like this:

Before we push this code to trunk, we want to add
support
for
it
in
XLSForm. The obvious way to do this is to add a new
column,
but
I
don't think it's sustainable in the long run for every
attribute
we
might want to add.

I wanted to bring this discussion to the community to
solicit
ideas.
Is the status quo of adding a named column what we
want?
Or
do
we
want
a more generic solution?

For example, any column with body::x as a header would
insert
x
as
an
attribute in the body XML? And bind::y would insert y
as
in
attribute
in the bind XML.

Good idea? Terrible idea?

Yaw

Need ODK services? http://nafundi.com provides form
design,
server
setup, professional support, and software development
for
ODK.

--
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.

--
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 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.

--
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/hgAXcRBkmAs/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.

--
Did you know that Enketo Smart Paper has now become the #1 tool for
data
collection? Don't fall behind. Use it!

Enketo | LinkedIn | GitHub | Twitter

--
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 a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit

https://groups.google.com/d/topic/opendatakit-developers/hgAXcRBkmAs/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.

--
Did you know that Enketo Smart Paper has now become the #1 tool for data
collection? Don't fall behind. Use it!

Enketo | LinkedIn | GitHub | Twitter

--
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 a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/hgAXcRBkmAs/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.

--
Did you know that Enketo Smart Paper has now become the #1 tool for data
collection? Don't fall behind. Use it!

Enketo | LinkedIn | GitHub | Twitter

--
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.