Can calculations function within Repeats?

Hi Will,

I think, you stumbled upon a known issue with calculated items inside
repeats in enketo: https://github.com/modilabs/enketo/issues/477. So it
will probably work in ODK Collect, but not yet in enketo. Once the issue is
marked as closed it will soon thereafter be deployed.

Cheers,
Martijn

··· On Thursday, June 6, 2013 11:42:26 AM UTC-6, abta...@gmail.com wrote: > > On Thursday, June 6, 2013 10:09:23 AM UTC-4, abta...@gmail.com wrote: > > I'm trying to do some simple addition and multiplication calculations > within a Repeat group. The calculations function for the first entry, but > fails for every additional entry. Can calculations function within repeats > beyond the first entry? And if they can, how do you configure the > calculation? > > > > Thanks, > > Will > > Apologies for not including more information. I'm attaching the .xls form > of the code in question. Here is also a link to the web form itself so the > behavior can be viewed: > > http://hlhy4.enketo.formhub.org/webform > > I have a calculate (name "othertotalcost") that multiples the Total Units > (integer type with name "othertotal") by the Total Cost (decimal type with > name "othercost"). This calculation functions for the first entry within > the repeat, but if any additional entries are attempted, the calculation > fails. > >

Support for calculations inside repeats has now been added to enketo!

A tip, related to this:
If you're coding XForms by hand, I recommend using ../relative paths when
referring to a node inside a repeat from another node inside the same
repeat (to prepare for the future where the use of (incorrect) absolute
paths in these cases will no longer be supported).

Cheers,
Martijn

··· On Friday, June 7, 2013 8:22:46 AM UTC-6, Martijn van de Rijdt wrote: > > Hi Will, > > I think, you stumbled upon a known issue with calculated items inside > repeats in enketo: https://github.com/modilabs/enketo/issues/477. So it > will probably work in ODK Collect, but not yet in enketo. Once the issue is > marked as closed it will soon thereafter be deployed. > > Cheers, > Martijn > > On Thursday, June 6, 2013 11:42:26 AM UTC-6, abta...@gmail.com wrote: >> >> On Thursday, June 6, 2013 10:09:23 AM UTC-4, abta...@gmail.com wrote: >> > I'm trying to do some simple addition and multiplication calculations >> within a Repeat group. The calculations function for the first entry, but >> fails for every additional entry. Can calculations function within repeats >> beyond the first entry? And if they can, how do you configure the >> calculation? >> > >> > Thanks, >> > Will >> >> Apologies for not including more information. I'm attaching the .xls >> form of the code in question. Here is also a link to the web form itself >> so the behavior can be viewed: >> >> http://hlhy4.enketo.formhub.org/webform >> >> I have a calculate (name "othertotalcost") that multiples the Total Units >> (integer type with name "othertotal") by the Total Cost (decimal type with >> name "othercost"). This calculation functions for the first entry within >> the repeat, but if any additional entries are attempted, the calculation >> fails. >> >>

Yes, within repeats, it is important to use relative access to values
within the repeat in a calculation. To my knowledge, XLSForm does not do
this entirely correctly; therefore, while the underlying engines (enketo,
javarosa) may support it, in may not be possible to use Build or XLSForm to
generate the proper calculate expressions.

Mitch

··· On Thu, Jun 13, 2013 at 2:25 PM, Martijn van de Rijdt < martijn@aidwebsolutions.com> wrote:

Support for calculations inside repeats has now been added to enketo!

A tip, related to this:
If you're coding XForms by hand, I recommend using ../relative paths when
referring to a node inside a repeat from another node inside the same
repeat (to prepare for the future where the use of (incorrect) absolute
paths in these cases will no longer be supported).

Cheers,
Martijn

On Friday, June 7, 2013 8:22:46 AM UTC-6, Martijn van de Rijdt wrote:

Hi Will,

I think, you stumbled upon a known issue with calculated items inside
repeats in enketo: https://github.com/**modilabs/enketo/issues/477https://github.com/modilabs/enketo/issues/477.
So it will probably work in ODK Collect, but not yet in enketo. Once the
issue is marked as closed it will soon thereafter be deployed.

Cheers,
Martijn

On Thursday, June 6, 2013 11:42:26 AM UTC-6, abta...@gmail.com wrote:

On Thursday, June 6, 2013 10:09:23 AM UTC-4, abta...@gmail.com wrote:

I'm trying to do some simple addition and multiplication calculations
within a Repeat group. The calculations function for the first entry, but
fails for every additional entry. Can calculations function within repeats
beyond the first entry? And if they can, how do you configure the
calculation?

Thanks,
Will

Apologies for not including more information. I'm attaching the .xls
form of the code in question. Here is also a link to the web form itself
so the behavior can be viewed:

http://hlhy4.enketo.formhub.**org/webformhttp://hlhy4.enketo.formhub.org/webform

I have a calculate (name "othertotalcost") that multiples the Total
Units (integer type with name "othertotal") by the Total Cost (decimal type
with name "othercost"). This calculation functions for the first entry
within the repeat, but if any additional entries are attempted, the
calculation fails.

--
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/groups/opt_out.

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

Now I'm confused: why would the use of absolute paths become illegal? Right
now, XLSForm always resolves ${fieldname} references into absolute, generic
references like /form/outergroup/repeatgroup/fieldname. It's generic in
that it's missing indexes, but those indexes get put in at run-time, based
on your current context (i.e., the absolute reference is "contextualized").
I'm clearly no XForms expert, but that hardly seems like errant behavior
that needs to be stamped out in the future. At the very least, any Collect
or enketo release that didn't support such references would be instantly
incompatible with essentially all XLSForm-generated forms to-date -- which
would seem like a pretty undesirable thing. Or am I missing something?

Chris

··· On Fri, Jun 14, 2013 at 3:43 AM, Mitch Sundt wrote:

Yes, within repeats, it is important to use relative access to values
within the repeat in a calculation. To my knowledge, XLSForm does not do
this entirely correctly; therefore, while the underlying engines (enketo,
javarosa) may support it, in may not be possible to use Build or XLSForm to
generate the proper calculate expressions.

Mitch

On Thu, Jun 13, 2013 at 2:25 PM, Martijn van de Rijdt < martijn@aidwebsolutions.com> wrote:

Support for calculations inside repeats has now been added to enketo!

A tip, related to this:
If you're coding XForms by hand, I recommend using ../relative paths when
referring to a node inside a repeat from another node inside the same
repeat (to prepare for the future where the use of (incorrect) absolute
paths in these cases will no longer be supported).

Cheers,
Martijn

On Friday, June 7, 2013 8:22:46 AM UTC-6, Martijn van de Rijdt wrote:

Hi Will,

I think, you stumbled upon a known issue with calculated items inside
repeats in enketo: https://github.com/**modilabs/enketo/issues/477https://github.com/modilabs/enketo/issues/477.
So it will probably work in ODK Collect, but not yet in enketo. Once the
issue is marked as closed it will soon thereafter be deployed.

Cheers,
Martijn

On Thursday, June 6, 2013 11:42:26 AM UTC-6, abta...@gmail.com wrote:

On Thursday, June 6, 2013 10:09:23 AM UTC-4, abta...@gmail.com wrote:

I'm trying to do some simple addition and multiplication calculations
within a Repeat group. The calculations function for the first entry, but
fails for every additional entry. Can calculations function within repeats
beyond the first entry? And if they can, how do you configure the
calculation?

Thanks,
Will

Apologies for not including more information. I'm attaching the .xls
form of the code in question. Here is also a link to the web form itself
so the behavior can be viewed:

http://hlhy4.enketo.formhub.**org/webformhttp://hlhy4.enketo.formhub.org/webform

I have a calculate (name "othertotalcost") that multiples the Total
Units (integer type with name "othertotal") by the Total Cost (decimal type
with name "othercost"). This calculation functions for the first entry
within the repeat, but if any additional entries are attempted, the
calculation fails.

--
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/groups/opt_out.

--
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/groups/opt_out.

There has been some discussion around this in XLS Forms here with
Nathan: https://github.com/modilabs/pyxform/issues/91

@Chris, certainly support for the incorrect XPaths inside repeats should
remain in place inside ODK Collect and Enketo for backwards compatibility
reasons. Best to start moving to the correct (XPath) way of doing things
though.

Injecting positions is an unnecessary hack because XPath already provides
elegant ways of directly referring to nodes inside repeats, without hacking.

@Will, to clarify the issue (as requested outside this thread):

This absolute path:* /data/repeat/node1* returns 2 nodes (or only the value
of the first node depending on the resultType you're requesting). So if
node2 needs to refer to the value of node 1 in each repeat, a relative path
should be used when building the form (by hand):* ../node1. *

··· * * Cheers, Martijn

On Friday, June 14, 2013 12:14:50 AM UTC-6, Chris wrote:

Now I'm confused: why would the use of absolute paths become illegal?
Right now, XLSForm always resolves ${fieldname} references into absolute,
generic references like /form/outergroup/repeatgroup/fieldname. It's
generic in that it's missing indexes, but those indexes get put in at
run-time, based on your current context (i.e., the absolute reference is
"contextualized"). I'm clearly no XForms expert, but that hardly seems like
errant behavior that needs to be stamped out in the future. At the very
least, any Collect or enketo release that didn't support such references
would be instantly incompatible with essentially all XLSForm-generated
forms to-date -- which would seem like a pretty undesirable thing. Or am I
missing something?

Chris

On Fri, Jun 14, 2013 at 3:43 AM, Mitch Sundt <mitche...@gmail.com<javascript:> wrote:

Yes, within repeats, it is important to use relative access to values
within the repeat in a calculation. To my knowledge, XLSForm does not do
this entirely correctly; therefore, while the underlying engines (enketo,
javarosa) may support it, in may not be possible to use Build or XLSForm to
generate the proper calculate expressions.

Mitch

On Thu, Jun 13, 2013 at 2:25 PM, Martijn van de Rijdt < mar...@aidwebsolutions.com <javascript:>> wrote:

Support for calculations inside repeats has now been added to enketo!

A tip, related to this:
If you're coding XForms by hand, I recommend using ../relative paths
when referring to a node inside a repeat from another node inside the same
repeat (to prepare for the future where the use of (incorrect) absolute
paths in these cases will no longer be supported).

Cheers,
Martijn

On Friday, June 7, 2013 8:22:46 AM UTC-6, Martijn van de Rijdt wrote:

Hi Will,

I think, you stumbled upon a known issue with calculated items inside
repeats in enketo: https://github.com/**modilabs/enketo/issues/477https://github.com/modilabs/enketo/issues/477.
So it will probably work in ODK Collect, but not yet in enketo. Once the
issue is marked as closed it will soon thereafter be deployed.

Cheers,
Martijn

On Thursday, June 6, 2013 11:42:26 AM UTC-6, abta...@gmail.com wrote:

On Thursday, June 6, 2013 10:09:23 AM UTC-4, abta...@gmail.com wrote:

I'm trying to do some simple addition and multiplication
calculations within a Repeat group. The calculations function for the
first entry, but fails for every additional entry. Can calculations
function within repeats beyond the first entry? And if they can, how do
you configure the calculation?

Thanks,
Will

Apologies for not including more information. I'm attaching the .xls
form of the code in question. Here is also a link to the web form itself
so the behavior can be viewed:

http://hlhy4.enketo.formhub.**org/webformhttp://hlhy4.enketo.formhub.org/webform

I have a calculate (name "othertotalcost") that multiples the Total
Units (integer type with name "othertotal") by the Total Cost (decimal type
with name "othercost"). This calculation functions for the first entry
within the repeat, but if any additional entries are attempted, the
calculation fails.

--
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<javascript:>
.
For more options, visit https://groups.google.com/groups/opt_out.

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com <javascript:>

--
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<javascript:>
.
For more options, visit https://groups.google.com/groups/opt_out.

I meant to say: should remain in place inside ODK Collect and Enketo for
quite a while longer
for backwards compatibility reasons.

··· On Friday, June 14, 2013 10:00:48 AM UTC-6, Martijn van de Rijdt wrote: > > There has been some discussion around this in XLS Forms here with Nathan: > https://github.com/modilabs/pyxform/issues/91 > > @Chris, certainly support for the incorrect XPaths inside repeats should > remain in place inside ODK Collect and Enketo for backwards compatibility > reasons. Best to start moving to the correct (XPath) way of doing things > though. > > Injecting positions is an unnecessary hack because XPath already provides > elegant ways of directly referring to nodes inside repeats, without hacking. > > @Will, to clarify the issue (as requested outside this thread): > > > > > > > > > > > > > This absolute path:* /data/repeat/node1* returns 2 nodes (or only the > value of the first node depending on the resultType you're requesting). So > if node2 needs to refer to the value of node 1 in each repeat, a relative > path should be used when building the form (by hand):* ../node1. * > * > * > Cheers, > Martijn > > > On Friday, June 14, 2013 12:14:50 AM UTC-6, Chris wrote: >> >> Now I'm confused: why would the use of absolute paths become illegal? >> Right now, XLSForm always resolves ${fieldname} references into absolute, >> generic references like /form/outergroup/repeatgroup/fieldname. It's >> generic in that it's missing indexes, but those indexes get put in at >> run-time, based on your current context (i.e., the absolute reference is >> "contextualized"). I'm clearly no XForms expert, but that hardly seems like >> errant behavior that needs to be stamped out in the future. At the very >> least, any Collect or enketo release that didn't support such references >> would be instantly incompatible with essentially all XLSForm-generated >> forms to-date -- which would seem like a pretty undesirable thing. Or am I >> missing something? >> >> Chris >> >> >> >> On Fri, Jun 14, 2013 at 3:43 AM, Mitch Sundt wrote: >> >>> Yes, within repeats, it is important to use relative access to values >>> within the repeat in a calculation. To my knowledge, XLSForm does not do >>> this entirely correctly; therefore, while the underlying engines (enketo, >>> javarosa) may support it, in may not be possible to use Build or XLSForm to >>> generate the proper calculate expressions. >>> >>> Mitch >>> >>> >>> >>> On Thu, Jun 13, 2013 at 2:25 PM, Martijn van de Rijdt < mar...@aidwebsolutions.com> wrote: >>> >>>> Support for calculations inside repeats has now been added to enketo! >>>> >>>> A tip, related to this: >>>> If you're coding XForms by hand, I recommend using ../relative paths >>>> when referring to a node inside a repeat from another node inside the same >>>> repeat (to prepare for the future where the use of (incorrect) absolute >>>> paths in these cases will no longer be supported). >>>> >>>> Cheers, >>>> Martijn >>>> >>>> On Friday, June 7, 2013 8:22:46 AM UTC-6, Martijn van de Rijdt wrote: >>>>> >>>>> Hi Will, >>>>> >>>>> I think, you stumbled upon a known issue with calculated items inside >>>>> repeats in enketo: https://github.com/**modilabs/enketo/issues/477. >>>>> So it will probably work in ODK Collect, but not yet in enketo. Once the >>>>> issue is marked as closed it will soon thereafter be deployed. >>>>> >>>>> Cheers, >>>>> Martijn >>>>> >>>>> On Thursday, June 6, 2013 11:42:26 AM UTC-6, abta...@gmail.com wrote: >>>>>> >>>>>> On Thursday, June 6, 2013 10:09:23 AM UTC-4, abta...@gmail.com wrote: >>>>>> > I'm trying to do some simple addition and multiplication >>>>>> calculations within a Repeat group. The calculations function for the >>>>>> first entry, but fails for every additional entry. Can calculations >>>>>> function within repeats beyond the first entry? And if they can, how do >>>>>> you configure the calculation? >>>>>> > >>>>>> > Thanks, >>>>>> > Will >>>>>> >>>>>> Apologies for not including more information. I'm attaching the .xls >>>>>> form of the code in question. Here is also a link to the web form itself >>>>>> so the behavior can be viewed: >>>>>> >>>>>> http://hlhy4.enketo.formhub.**org/webform >>>>>> >>>>>> I have a calculate (name "othertotalcost") that multiples the Total >>>>>> Units (integer type with name "othertotal") by the Total Cost (decimal type >>>>>> with name "othercost"). This calculation functions for the first entry >>>>>> within the repeat, but if any additional entries are attempted, the >>>>>> calculation fails. >>>>>> >>>>>> -- >>>> 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/groups/opt_out. >>>> >>>> >>>> >>> >>> >>> >>> -- >>> 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/groups/opt_out. >>> >>> >>> >> >>

Hi Martijn,

Thanks for the reply. I have to admit, though, that I'm still a bit
confused. While shifting to relative paths seems perfectly fine for cases
where you're referencing variables within the current repeat instance, it
doesn't seem desirable to ever completely phase out absolute path
references. After all, what we're just starting to be able to do is
reference across repeat-group instances in flexible ways, which is critical
for a whole range of applications. For referencing repeated fields from
other contexts
, it would seem that absolute paths would be necessary.

Take a simple example that recurs in a great many surveys: you have a
"household roster" repeat at the beginning of your form to collect some
basic details on every household member, but then it would be extremely
awkward to only ever ask follow-up questions about household members within
that early repeat; later on in the survey, you may start asking questions
about jobs, or about health, or about all manner of other things, and in
those later sections you may well want to refer back to household members'
details. You want to populate select_one and select_multiple lists with the
household member names, you want to check ages to make sure that you only
ask about number for children for women over 12 years old, etc., etc. These
are very common things to want to do.

Traditionally, doing these things has been extremely difficult if you use
repeat groups, because of the difficulty referencing specific values within
earlier groups. In principle, absolute paths like /form/repeatgroup[3]/name
provided a clear solution, but the predicate and context support in the
current ODK branch of JavaRosa has made it somewhat challenging to
construct those references in a way that is interpreted properly at
run-time. /form/repeatgroup[position() = /form/laterrepeatgroup/pos]/name
is maybe supposed to work, but doesn't, and generally there has been a lot
of heart-ache and confusion over how to do this stuff.

We have recently added an indexed-repeat() function to our own JavaRosa
branch (discussed here in another thread), and have submitted that for
potential inclusion in the ODK JavaRosa branch. It essentially allows you
to flexibly supply the repeat instance indexes to fill in the x's and y's
in paths like /form/outerrepeat/innerrepeat[y]/name. It's a very simple
function, but it opens up a whole range of applications, like those
discussed just above.

indexed-repeat() takes any XPaths, and so supports relative paths like
anything else. But, its raison d'etre is references across contexts, in
which relative references are far less useful. Is there a method for doing
cross-context referencing that you envision not relying on absolute paths?

Thanks again,

Chris

··· On Fri, Jun 14, 2013 at 6:00 PM, Martijn van de Rijdt < martijn@aidwebsolutions.com> wrote:

There has been some discussion around this in XLS Forms here with Nathan:
https://github.com/modilabs/pyxform/issues/91

@Chris, certainly support for the incorrect XPaths inside repeats should
remain in place inside ODK Collect and Enketo for backwards compatibility
reasons. Best to start moving to the correct (XPath) way of doing things
though.

Injecting positions is an unnecessary hack because XPath already provides
elegant ways of directly referring to nodes inside repeats, without hacking.

@Will, to clarify the issue (as requested outside this thread):

This absolute path:* /data/repeat/node1* returns 2 nodes (or only the
value of the first node depending on the resultType you're requesting). So
if node2 needs to refer to the value of node 1 in each repeat, a relative
path should be used when building the form (by hand):* ../node1. *
*
*
Cheers,
Martijn

On Friday, June 14, 2013 12:14:50 AM UTC-6, Chris wrote:

Now I'm confused: why would the use of absolute paths become illegal?
Right now, XLSForm always resolves ${fieldname} references into absolute,
generic references like /form/outergroup/repeatgroup/**fieldname. It's
generic in that it's missing indexes, but those indexes get put in at
run-time, based on your current context (i.e., the absolute reference is
"contextualized"). I'm clearly no XForms expert, but that hardly seems like
errant behavior that needs to be stamped out in the future. At the very
least, any Collect or enketo release that didn't support such references
would be instantly incompatible with essentially all XLSForm-generated
forms to-date -- which would seem like a pretty undesirable thing. Or am I
missing something?

Chris

On Fri, Jun 14, 2013 at 3:43 AM, Mitch Sundt mitche...@gmail.com wrote:

Yes, within repeats, it is important to use relative access to values
within the repeat in a calculation. To my knowledge, XLSForm does not do
this entirely correctly; therefore, while the underlying engines (enketo,
javarosa) may support it, in may not be possible to use Build or XLSForm to
generate the proper calculate expressions.

Mitch

On Thu, Jun 13, 2013 at 2:25 PM, Martijn van de Rijdt < mar...@aidwebsolutions.com> wrote:

Support for calculations inside repeats has now been added to enketo!

A tip, related to this:
If you're coding XForms by hand, I recommend using ../relative paths
when referring to a node inside a repeat from another node inside the same
repeat (to prepare for the future where the use of (incorrect) absolute
paths in these cases will no longer be supported).

Cheers,
Martijn

On Friday, June 7, 2013 8:22:46 AM UTC-6, Martijn van de Rijdt wrote:

Hi Will,

I think, you stumbled upon a known issue with calculated items inside
repeats in enketo: https://github.com/**mod**ilabs/enketo/issues/477https://github.com/modilabs/enketo/issues/477.
So it will probably work in ODK Collect, but not yet in enketo. Once the
issue is marked as closed it will soon thereafter be deployed.

Cheers,
Martijn

On Thursday, June 6, 2013 11:42:26 AM UTC-6, abta...@gmail.com wrote:

On Thursday, June 6, 2013 10:09:23 AM UTC-4, abta...@gmail.com wrote:

I'm trying to do some simple addition and multiplication
calculations within a Repeat group. The calculations function for the
first entry, but fails for every additional entry. Can calculations
function within repeats beyond the first entry? And if they can, how do
you configure the calculation?

Thanks,
Will

Apologies for not including more information. I'm attaching the .xls
form of the code in question. Here is also a link to the web form itself
so the behavior can be viewed:

http://hlhy4.enketo.formhub.org/webformhttp://hlhy4.enketo.formhub.org/webform

I have a calculate (name "othertotalcost") that multiples the Total
Units (integer type with name "othertotal") by the Total Cost (decimal type
with name "othercost"). This calculation functions for the first entry
within the repeat, but if any additional entries are attempted, the
calculation fails.

--
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/**groups/opt_outhttps://groups.google.com/groups/opt_out
.

--
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/**groups/opt_outhttps://groups.google.com/groups/opt_out
.

--
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/groups/opt_out.

One thing to note here is that you can use relative paths in XLSForms
instead of the ${variable} syntax.
Regards,
-Nathan

Hi Chris,

Yes, the issue we were referring to was only for referring to nodes within
repeats from the same repeat. In all other contexts absolute paths should
be fine if nodeNames are kept unique - which strictly speaking may not be
required - except for the issue you described with [index] in /data/repeat
[3]/node not yet being supported in javaRosa (it is supported in enketo).

I need to have a look at the indexed-repeat function/thread for the latter
issue. So if I understand you correctly, this new function would not be
necessary if standard XPath [index] was supported, right?

Cheers,
Martijn

··· On Tue, Jun 18, 2013 at 12:59 AM, Christopher Robert <chrislrobert@gmail.com wrote:

Hi Martijn,

Thanks for the reply. I have to admit, though, that I'm still a bit
confused. While shifting to relative paths seems perfectly fine for cases
where you're referencing variables within the current repeat instance, it
doesn't seem desirable to ever completely phase out absolute path
references. After all, what we're just starting to be able to do is
reference across repeat-group instances in flexible ways, which is critical
for a whole range of applications. For referencing repeated fields from
other contexts
, it would seem that absolute paths would be necessary.

Take a simple example that recurs in a great many surveys: you have a
"household roster" repeat at the beginning of your form to collect some
basic details on every household member, but then it would be extremely
awkward to only ever ask follow-up questions about household members within
that early repeat; later on in the survey, you may start asking questions
about jobs, or about health, or about all manner of other things, and in
those later sections you may well want to refer back to household members'
details. You want to populate select_one and select_multiple lists with the
household member names, you want to check ages to make sure that you only
ask about number for children for women over 12 years old, etc., etc. These
are very common things to want to do.

Traditionally, doing these things has been extremely difficult if you use
repeat groups, because of the difficulty referencing specific values within
earlier groups. In principle, absolute paths like /form/repeatgroup[3]/name
provided a clear solution, but the predicate and context support in the
current ODK branch of JavaRosa has made it somewhat challenging to
construct those references in a way that is interpreted properly at
run-time. /form/repeatgroup[position() = /form/laterrepeatgroup/pos]/name
is maybe supposed to work, but doesn't, and generally there has been a lot
of heart-ache and confusion over how to do this stuff.

We have recently added an indexed-repeat() function to our own JavaRosa
branch (discussed here in another thread), and have submitted that for
potential inclusion in the ODK JavaRosa branch. It essentially allows you
to flexibly supply the repeat instance indexes to fill in the x's and y's
in paths like /form/outerrepeat/innerrepeat[y]/name. It's a very simple
function, but it opens up a whole range of applications, like those
discussed just above.

indexed-repeat() takes any XPaths, and so supports relative paths like
anything else. But, its raison d'etre is references across contexts, in
which relative references are far less useful. Is there a method for doing
cross-context referencing that you envision not relying on absolute paths?

Thanks again,

Chris

On Fri, Jun 14, 2013 at 6:00 PM, Martijn van de Rijdt < martijn@aidwebsolutions.com> wrote:

There has been some discussion around this in XLS Forms here with Nathan:
https://github.com/modilabs/pyxform/issues/91

@Chris, certainly support for the incorrect XPaths inside repeats should
remain in place inside ODK Collect and Enketo for backwards compatibility
reasons. Best to start moving to the correct (XPath) way of doing things
though.

Injecting positions is an unnecessary hack because XPath already provides
elegant ways of directly referring to nodes inside repeats, without hacking.

@Will, to clarify the issue (as requested outside this thread):

This absolute path:* /data/repeat/node1* returns 2 nodes (or only the
value of the first node depending on the resultType you're requesting). So
if node2 needs to refer to the value of node 1 in each repeat, a relative
path should be used when building the form (by hand):* ../node1. *
*
*
Cheers,
Martijn

On Friday, June 14, 2013 12:14:50 AM UTC-6, Chris wrote:

Now I'm confused: why would the use of absolute paths become illegal?
Right now, XLSForm always resolves ${fieldname} references into absolute,
generic references like /form/outergroup/repeatgroup/**fieldname. It's
generic in that it's missing indexes, but those indexes get put in at
run-time, based on your current context (i.e., the absolute reference is
"contextualized"). I'm clearly no XForms expert, but that hardly seems like
errant behavior that needs to be stamped out in the future. At the very
least, any Collect or enketo release that didn't support such references
would be instantly incompatible with essentially all XLSForm-generated
forms to-date -- which would seem like a pretty undesirable thing. Or am I
missing something?

Chris

On Fri, Jun 14, 2013 at 3:43 AM, Mitch Sundt mitche...@gmail.comwrote:

Yes, within repeats, it is important to use relative access to values
within the repeat in a calculation. To my knowledge, XLSForm does not do
this entirely correctly; therefore, while the underlying engines (enketo,
javarosa) may support it, in may not be possible to use Build or XLSForm to
generate the proper calculate expressions.

Mitch

On Thu, Jun 13, 2013 at 2:25 PM, Martijn van de Rijdt < mar...@aidwebsolutions.com> wrote:

Support for calculations inside repeats has now been added to enketo!

A tip, related to this:
If you're coding XForms by hand, I recommend using ../relative paths
when referring to a node inside a repeat from another node inside the same
repeat (to prepare for the future where the use of (incorrect) absolute
paths in these cases will no longer be supported).

Cheers,
Martijn

On Friday, June 7, 2013 8:22:46 AM UTC-6, Martijn van de Rijdt wrote:

Hi Will,

I think, you stumbled upon a known issue with calculated items inside
repeats in enketo: https://github.com/**mod**ilabs/enketo/issues/477https://github.com/modilabs/enketo/issues/477.
So it will probably work in ODK Collect, but not yet in enketo. Once the
issue is marked as closed it will soon thereafter be deployed.

Cheers,
Martijn

On Thursday, June 6, 2013 11:42:26 AM UTC-6, abta...@gmail.com wrote:

On Thursday, June 6, 2013 10:09:23 AM UTC-4, abta...@gmail.comwrote:

I'm trying to do some simple addition and multiplication
calculations within a Repeat group. The calculations function for the
first entry, but fails for every additional entry. Can calculations
function within repeats beyond the first entry? And if they can, how do
you configure the calculation?

Thanks,
Will

Apologies for not including more information. I'm attaching the
.xls form of the code in question. Here is also a link to the web form
itself so the behavior can be viewed:

http://hlhy4.enketo.formhub.org/webformhttp://hlhy4.enketo.formhub.org/webform

I have a calculate (name "othertotalcost") that multiples the Total
Units (integer type with name "othertotal") by the Total Cost (decimal type
with name "othercost"). This calculation functions for the first entry
within the repeat, but if any additional entries are attempted, the
calculation fails.

--
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/**groups/opt_outhttps://groups.google.com/groups/opt_out
.

--
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/**groups/opt_outhttps://groups.google.com/groups/opt_out
.

--
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/groups/opt_out.

--
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/7b3FohKkmRs/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/groups/opt_out.

Note that [3] is equivalent to [position()=3], so this is supported in
javarosa, but not using this syntax.

The javarosa parser just needs to transform [integerexpression] into such a
boolean constraint predicate. That should be a fairly easy rewrite rule to
implement on the JR XPathExpr parser.

··· On Tue, Jun 18, 2013 at 8:17 AM, Martijn van de Rijdt wrote:

Hi Chris,

Yes, the issue we were referring to was only for referring to nodes within
repeats from the same repeat. In all other contexts absolute paths should
be fine if nodeNames are kept unique - which strictly speaking may not be
required - except for the issue you described with [index] in /data/repeat
[3]/node not yet being supported in javaRosa (it is supported in
enketo).

I need to have a look at the indexed-repeat function/thread for the latter
issue. So if I understand you correctly, this new function would not be
necessary if standard XPath [index] was supported, right?

Cheers,
Martijn

On Tue, Jun 18, 2013 at 12:59 AM, Christopher Robert < chrislrobert@gmail.com> wrote:

Hi Martijn,

Thanks for the reply. I have to admit, though, that I'm still a bit
confused. While shifting to relative paths seems perfectly fine for cases
where you're referencing variables within the current repeat instance, it
doesn't seem desirable to ever completely phase out absolute path
references. After all, what we're just starting to be able to do is
reference across repeat-group instances in flexible ways, which is critical
for a whole range of applications. For referencing repeated fields from
other contexts
, it would seem that absolute paths would be necessary.

Take a simple example that recurs in a great many surveys: you have a
"household roster" repeat at the beginning of your form to collect some
basic details on every household member, but then it would be extremely
awkward to only ever ask follow-up questions about household members within
that early repeat; later on in the survey, you may start asking questions
about jobs, or about health, or about all manner of other things, and in
those later sections you may well want to refer back to household members'
details. You want to populate select_one and select_multiple lists with the
household member names, you want to check ages to make sure that you only
ask about number for children for women over 12 years old, etc., etc. These
are very common things to want to do.

Traditionally, doing these things has been extremely difficult if you use
repeat groups, because of the difficulty referencing specific values within
earlier groups. In principle, absolute paths like /form/repeatgroup[3]/name
provided a clear solution, but the predicate and context support in the
current ODK branch of JavaRosa has made it somewhat challenging to
construct those references in a way that is interpreted properly at
run-time. /form/repeatgroup[position() = /form/laterrepeatgroup/pos]/name
is maybe supposed to work, but doesn't, and generally there has been a lot
of heart-ache and confusion over how to do this stuff.

We have recently added an indexed-repeat() function to our own JavaRosa
branch (discussed here in another thread), and have submitted that for
potential inclusion in the ODK JavaRosa branch. It essentially allows you
to flexibly supply the repeat instance indexes to fill in the x's and y's
in paths like /form/outerrepeat/innerrepeat[y]/name. It's a very simple
function, but it opens up a whole range of applications, like those
discussed just above.

indexed-repeat() takes any XPaths, and so supports relative paths like
anything else. But, its raison d'etre is references across contexts, in
which relative references are far less useful. Is there a method for doing
cross-context referencing that you envision not relying on absolute paths?

Thanks again,

Chris

On Fri, Jun 14, 2013 at 6:00 PM, Martijn van de Rijdt < martijn@aidwebsolutions.com> wrote:

There has been some discussion around this in XLS Forms here with
Nathan: https://github.com/modilabs/pyxform/issues/91

@Chris, certainly support for the incorrect XPaths inside repeats should
remain in place inside ODK Collect and Enketo for backwards compatibility
reasons. Best to start moving to the correct (XPath) way of doing things
though.

Injecting positions is an unnecessary hack because XPath already
provides elegant ways of directly referring to nodes inside repeats,
without hacking.

@Will, to clarify the issue (as requested outside this thread):

This absolute path:* /data/repeat/node1* returns 2 nodes (or only the
value of the first node depending on the resultType you're requesting). So
if node2 needs to refer to the value of node 1 in each repeat, a relative
path should be used when building the form (by hand):* ../node1. *
*
*
Cheers,
Martijn

On Friday, June 14, 2013 12:14:50 AM UTC-6, Chris wrote:

Now I'm confused: why would the use of absolute paths become illegal?
Right now, XLSForm always resolves ${fieldname} references into absolute,
generic references like /form/outergroup/repeatgroup/**fieldname. It's
generic in that it's missing indexes, but those indexes get put in at
run-time, based on your current context (i.e., the absolute reference is
"contextualized"). I'm clearly no XForms expert, but that hardly seems like
errant behavior that needs to be stamped out in the future. At the very
least, any Collect or enketo release that didn't support such references
would be instantly incompatible with essentially all XLSForm-generated
forms to-date -- which would seem like a pretty undesirable thing. Or am I
missing something?

Chris

On Fri, Jun 14, 2013 at 3:43 AM, Mitch Sundt mitche...@gmail.comwrote:

Yes, within repeats, it is important to use relative access to values
within the repeat in a calculation. To my knowledge, XLSForm does not do
this entirely correctly; therefore, while the underlying engines (enketo,
javarosa) may support it, in may not be possible to use Build or XLSForm to
generate the proper calculate expressions.

Mitch

On Thu, Jun 13, 2013 at 2:25 PM, Martijn van de Rijdt < mar...@aidwebsolutions.com> wrote:

Support for calculations inside repeats has now been added to enketo!

A tip, related to this:
If you're coding XForms by hand, I recommend using ../relative paths
when referring to a node inside a repeat from another node inside the same
repeat (to prepare for the future where the use of (incorrect) absolute
paths in these cases will no longer be supported).

Cheers,
Martijn

On Friday, June 7, 2013 8:22:46 AM UTC-6, Martijn van de Rijdt wrote:

Hi Will,

I think, you stumbled upon a known issue with calculated items
inside repeats in enketo: https://github.com/**mod**
ilabs/enketo/issues/477https://github.com/modilabs/enketo/issues/477.
So it will probably work in ODK Collect, but not yet in enketo. Once the
issue is marked as closed it will soon thereafter be deployed.

Cheers,
Martijn

On Thursday, June 6, 2013 11:42:26 AM UTC-6, abta...@gmail.comwrote:

On Thursday, June 6, 2013 10:09:23 AM UTC-4, abta...@gmail.comwrote:

I'm trying to do some simple addition and multiplication
calculations within a Repeat group. The calculations function for the
first entry, but fails for every additional entry. Can calculations
function within repeats beyond the first entry? And if they can, how do
you configure the calculation?

Thanks,
Will

Apologies for not including more information. I'm attaching the
.xls form of the code in question. Here is also a link to the web form
itself so the behavior can be viewed:

http://hlhy4.enketo.formhub.org/webformhttp://hlhy4.enketo.formhub.org/webform

I have a calculate (name "othertotalcost") that multiples the Total
Units (integer type with name "othertotal") by the Total Cost (decimal type
with name "othercost"). This calculation functions for the first entry
within the repeat, but if any additional entries are attempted, the
calculation fails.

--
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/**groups/opt_outhttps://groups.google.com/groups/opt_out
.

--
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/**groups/opt_outhttps://groups.google.com/groups/opt_out
.

--
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/groups/opt_out.

--
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/7b3FohKkmRs/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/groups/opt_out.

--
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/groups/opt_out.

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

Hi Martijn,

Within JavaRosa, the multiplicity indexes are often output as just "[3]"
(e.g., when TreeReferences are converted to string paths), but, as Mitch
says, the proper syntax for referencing specific indexes is probably
"[position() = 3]". However, I could not get predicates like those to work
with the current Collect, which is why I gave up and implemented
indexed-repeat(). If predicates like "[position() = 3]" worked, then it
would be a matter of devising a syntax for indicating those indexes within
XLSForm's ${fieldname} references.

Note also, however, that you typically want to index based on the current
repeat group's index, or based on an index stored in a field. So, for
example, you'd want to do something like "[position() = position(..)]" or
"[position() = /form/posfield]". The latter is probably no trouble, but the
former may be difficult. Note that the former is the classic case where you
have an early repeat group for defining, say, household member names, and
then a later, parallel repeat group for asking follow-up questions. You
want, in each instance of the later group, to reference the same-numbered
instance in the earlier group.

indexed-repeat() has the advantage that it seems to work well for both
XLSForm and straight XForm definitions, and it side-steps complex predicate
syntax that may or may not actually function at present. I can appreciate,
though, a preference for an approach that better fits within the XForm
standard. If such an approach is devised and made to work, then perhaps the
XLSForm syntax could be extended accordingly.

Best,

Chris

··· On Tue, Jun 18, 2013 at 5:17 PM, Martijn van de Rijdt wrote:

Hi Chris,

Yes, the issue we were referring to was only for referring to nodes within
repeats from the same repeat. In all other contexts absolute paths should
be fine if nodeNames are kept unique - which strictly speaking may not be
required - except for the issue you described with [index] in /data/repeat
[3]/node not yet being supported in javaRosa (it is supported in
enketo).

I need to have a look at the indexed-repeat function/thread for the latter
issue. So if I understand you correctly, this new function would not be
necessary if standard XPath [index] was supported, right?

Cheers,
Martijn

On Tue, Jun 18, 2013 at 12:59 AM, Christopher Robert < chrislrobert@gmail.com> wrote:

Hi Martijn,

Thanks for the reply. I have to admit, though, that I'm still a bit
confused. While shifting to relative paths seems perfectly fine for cases
where you're referencing variables within the current repeat instance, it
doesn't seem desirable to ever completely phase out absolute path
references. After all, what we're just starting to be able to do is
reference across repeat-group instances in flexible ways, which is critical
for a whole range of applications. For referencing repeated fields from
other contexts
, it would seem that absolute paths would be necessary.

Take a simple example that recurs in a great many surveys: you have a
"household roster" repeat at the beginning of your form to collect some
basic details on every household member, but then it would be extremely
awkward to only ever ask follow-up questions about household members within
that early repeat; later on in the survey, you may start asking questions
about jobs, or about health, or about all manner of other things, and in
those later sections you may well want to refer back to household members'
details. You want to populate select_one and select_multiple lists with the
household member names, you want to check ages to make sure that you only
ask about number for children for women over 12 years old, etc., etc. These
are very common things to want to do.

Traditionally, doing these things has been extremely difficult if you use
repeat groups, because of the difficulty referencing specific values within
earlier groups. In principle, absolute paths like /form/repeatgroup[3]/name
provided a clear solution, but the predicate and context support in the
current ODK branch of JavaRosa has made it somewhat challenging to
construct those references in a way that is interpreted properly at
run-time. /form/repeatgroup[position() = /form/laterrepeatgroup/pos]/name
is maybe supposed to work, but doesn't, and generally there has been a lot
of heart-ache and confusion over how to do this stuff.

We have recently added an indexed-repeat() function to our own JavaRosa
branch (discussed here in another thread), and have submitted that for
potential inclusion in the ODK JavaRosa branch. It essentially allows you
to flexibly supply the repeat instance indexes to fill in the x's and y's
in paths like /form/outerrepeat/innerrepeat[y]/name. It's a very simple
function, but it opens up a whole range of applications, like those
discussed just above.

indexed-repeat() takes any XPaths, and so supports relative paths like
anything else. But, its raison d'etre is references across contexts, in
which relative references are far less useful. Is there a method for doing
cross-context referencing that you envision not relying on absolute paths?

Thanks again,

Chris

On Fri, Jun 14, 2013 at 6:00 PM, Martijn van de Rijdt < martijn@aidwebsolutions.com> wrote:

There has been some discussion around this in XLS Forms here with
Nathan: https://github.com/modilabs/pyxform/issues/91

@Chris, certainly support for the incorrect XPaths inside repeats should
remain in place inside ODK Collect and Enketo for backwards compatibility
reasons. Best to start moving to the correct (XPath) way of doing things
though.

Injecting positions is an unnecessary hack because XPath already
provides elegant ways of directly referring to nodes inside repeats,
without hacking.

@Will, to clarify the issue (as requested outside this thread):

This absolute path:* /data/repeat/node1* returns 2 nodes (or only the
value of the first node depending on the resultType you're requesting). So
if node2 needs to refer to the value of node 1 in each repeat, a relative
path should be used when building the form (by hand):* ../node1. *
*
*
Cheers,
Martijn

On Friday, June 14, 2013 12:14:50 AM UTC-6, Chris wrote:

Now I'm confused: why would the use of absolute paths become illegal?
Right now, XLSForm always resolves ${fieldname} references into absolute,
generic references like /form/outergroup/repeatgroup/**fieldname. It's
generic in that it's missing indexes, but those indexes get put in at
run-time, based on your current context (i.e., the absolute reference is
"contextualized"). I'm clearly no XForms expert, but that hardly seems like
errant behavior that needs to be stamped out in the future. At the very
least, any Collect or enketo release that didn't support such references
would be instantly incompatible with essentially all XLSForm-generated
forms to-date -- which would seem like a pretty undesirable thing. Or am I
missing something?

Chris

On Fri, Jun 14, 2013 at 3:43 AM, Mitch Sundt mitche...@gmail.comwrote:

Yes, within repeats, it is important to use relative access to values
within the repeat in a calculation. To my knowledge, XLSForm does not do
this entirely correctly; therefore, while the underlying engines (enketo,
javarosa) may support it, in may not be possible to use Build or XLSForm to
generate the proper calculate expressions.

Mitch

On Thu, Jun 13, 2013 at 2:25 PM, Martijn van de Rijdt < mar...@aidwebsolutions.com> wrote:

Support for calculations inside repeats has now been added to enketo!

A tip, related to this:
If you're coding XForms by hand, I recommend using ../relative paths
when referring to a node inside a repeat from another node inside the same
repeat (to prepare for the future where the use of (incorrect) absolute
paths in these cases will no longer be supported).

Cheers,
Martijn

On Friday, June 7, 2013 8:22:46 AM UTC-6, Martijn van de Rijdt wrote:

Hi Will,

I think, you stumbled upon a known issue with calculated items
inside repeats in enketo: https://github.com/**mod**
ilabs/enketo/issues/477https://github.com/modilabs/enketo/issues/477.
So it will probably work in ODK Collect, but not yet in enketo. Once the
issue is marked as closed it will soon thereafter be deployed.

Cheers,
Martijn

On Thursday, June 6, 2013 11:42:26 AM UTC-6, abta...@gmail.comwrote:

On Thursday, June 6, 2013 10:09:23 AM UTC-4, abta...@gmail.comwrote:

I'm trying to do some simple addition and multiplication
calculations within a Repeat group. The calculations function for the
first entry, but fails for every additional entry. Can calculations
function within repeats beyond the first entry? And if they can, how do
you configure the calculation?

Thanks,
Will

Apologies for not including more information. I'm attaching the
.xls form of the code in question. Here is also a link to the web form
itself so the behavior can be viewed:

http://hlhy4.enketo.formhub.org/webformhttp://hlhy4.enketo.formhub.org/webform

I have a calculate (name "othertotalcost") that multiples the Total
Units (integer type with name "othertotal") by the Total Cost (decimal type
with name "othercost"). This calculation functions for the first entry
within the repeat, but if any additional entries are attempted, the
calculation fails.

--
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/**groups/opt_outhttps://groups.google.com/groups/opt_out
.

--
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/**groups/opt_outhttps://groups.google.com/groups/opt_out
.

--
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/groups/opt_out.

--
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/7b3FohKkmRs/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/groups/opt_out.

--
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/groups/opt_out.