Odk validate 1.3 released

hello all,

i just pushed odk validate 1.3 to the website.

validate 1.3 is a minor release that updates the javarosa library so
it matches the version we are shipping in collect 1.1.5. the change
will ensure you get consistent validation error messages across both
applications.

yaw

Thanks, Yaw. This is a nice update. I have a few questions.

WARNING: choice value [...] is too long; max. suggested length 32 chars
Will a choice value with length longer than 32 characters mess up ODK
Collect or is this just a suggestion to work nicely with ODK Aggregate and
its siblings?

Should I use 'xmlns' or 'id' to identify XForms? It seems that Validate and
Collect have a preference for 'xmlns' but 'id' will still work.

ODK Validate doesn't seem to know about how to take pictures. Maybe I should
file this in an issue tracker.
Warning: 1 Unrecognized attributes found in Element [upload] and will be
ignored: [mediatype] Location:

Problem found at nodeset: /html/body/upload
With element

Warning: 1 Unrecognized attributes found in Element [upload] and will be
ignored: [ref] Location:

Problem found at nodeset: /html/body/upload
With element

Thanks again,

Andrew

··· On Thu, Feb 17, 2011 at 1:44 PM, Yaw Anokwa wrote: > hello all, > > i just pushed odk validate 1.3 to the website. > > validate 1.3 is a minor release that updates the javarosa library so > it matches the version we are shipping in collect 1.1.5. the change > will ensure you get consistent validation error messages across both > applications. > > yaw > > -- > Post: opendatakit@googlegroups.com > Unsubscribe: opendatakit+unsubscribe@googlegroups.com > Options: http://groups.google.com/group/opendatakit?hl=en >

re: xmlns vs. id.

Going forward, with Aggregate 1.0 and the OpenRosa XForms metadata standards
( https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema ), I
recommend using 'id' over 'xmlns' when naming a form. 'id' has the
advantage that we can eventually extend Aggregate to recognize different
versions of the same form through the treatment of 'version' and 'uiVersion'
tags.

Mitch

··· On Sat, Feb 19, 2011 at 2:26 PM, Andrew Marder wrote:

Thanks, Yaw. This is a nice update. I have a few questions.

WARNING: choice value [...] is too long; max. suggested length 32 chars
Will a choice value with length longer than 32 characters mess up ODK
Collect or is this just a suggestion to work nicely with ODK Aggregate and
its siblings?

Should I use 'xmlns' or 'id' to identify XForms? It seems that Validate and
Collect have a preference for 'xmlns' but 'id' will still work.

ODK Validate doesn't seem to know about how to take pictures. Maybe I
should file this in an issue tracker.
Warning: 1 Unrecognized attributes found in Element [upload] and will be
ignored: [mediatype] Location:

Problem found at nodeset: /html/body/upload

With element

Warning: 1 Unrecognized attributes found in Element [upload] and will be
ignored: [ref] Location:

Problem found at nodeset: /html/body/upload
With element

Thanks again,

Andrew

On Thu, Feb 17, 2011 at 1:44 PM, Yaw Anokwa yanokwa@gmail.com wrote:

hello all,

i just pushed odk validate 1.3 to the website.

validate 1.3 is a minor release that updates the javarosa library so
it matches the version we are shipping in collect 1.1.5. the change
will ensure you get consistent validation error messages across both
applications.

yaw

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer


University of Washington
mitchellsundt@gmail.com

re: choice item length. i think there was a good reason for this, but
i don't remember. i've posted the question to the javarosa-developers
list (http://groups.google.com/group/javarosa-developers/t/4f53b22c71b18b26)
and will let you know when i know.

··· On Tue, Feb 22, 2011 at 13:01, Mitch Sundt wrote: > re: xmlns vs. id. > > Going forward, with Aggregate 1.0 and the OpenRosa XForms metadata standards > ( https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema ), I > recommend using 'id' over 'xmlns' when naming a form. 'id' has the > advantage that we can eventually extend Aggregate to recognize different > versions of the same form through the treatment of 'version' and 'uiVersion' > tags. > > Mitch > > On Sat, Feb 19, 2011 at 2:26 PM, Andrew Marder wrote: >> >> Thanks, Yaw. This is a nice update. I have a few questions. >> >> WARNING: choice value [...] is too long; max. suggested length 32 chars >> Will a choice value with length longer than 32 characters mess up ODK >> Collect or is this just a suggestion to work nicely with ODK Aggregate and >> its siblings? >> >> Should I use 'xmlns' or 'id' to identify XForms? It seems that Validate >> and Collect have a preference for 'xmlns' but 'id' will still work. >> >> ODK Validate doesn't seem to know about how to take pictures. Maybe I >> should file this in an issue tracker. >> Warning: 1 Unrecognized attributes found in Element [upload] and will be >> ignored: [mediatype] Location: >> >> Problem found at nodeset: /html/body/upload >> With element >> >> Warning: 1 Unrecognized attributes found in Element [upload] and will be >> ignored: [ref] Location: >> >> Problem found at nodeset: /html/body/upload >> With element >> >> Thanks again, >> >> Andrew >> >> On Thu, Feb 17, 2011 at 1:44 PM, Yaw Anokwa wrote: >> > hello all, >> > >> > i just pushed odk validate 1.3 to the website. >> > >> > validate 1.3 is a minor release that updates the javarosa library so >> > it matches the version we are shipping in collect 1.1.5. the change >> > will ensure you get consistent validation error messages across both >> > applications. >> > >> > yaw >> > >> > -- >> > Post: opendatakit@googlegroups.com >> > Unsubscribe: opendatakit+unsubscribe@googlegroups.com >> > Options: http://groups.google.com/group/opendatakit?hl=en >> > >> >> -- >> Post: opendatakit@googlegroups.com >> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >> Options: http://groups.google.com/group/opendatakit?hl=en > > > > -- > Mitch Sundt > Software Engineer > http://www.OpenDataKit.org > University of Washington > mitchellsundt@gmail.com > > -- > Post: opendatakit@googlegroups.com > Unsubscribe: opendatakit+unsubscribe@googlegroups.com > Options: http://groups.google.com/group/opendatakit?hl=en >

"it is just a suggestion to avoid problems certain popular...
less-than-robust database backends. JR core handles it just fine."
-- drew

this shouldn't affect collect at all. pretty sure it doesn't affect
aggregate or build. i'm assuming mitch, waylon and clint will correct me if
i'm wrong.

··· On Wed, Feb 23, 2011 at 11:38, Yaw Anokwa wrote: > re: choice item length. i think there was a good reason for this, but > i don't remember. i've posted the question to the javarosa-developers > list (http://groups.google.com/group/javarosa-developers/t/4f53b22c71b18b26) > and will let you know when i know. > > On Tue, Feb 22, 2011 at 13:01, Mitch Sundt wrote: >> re: xmlns vs. id. >> >> Going forward, with Aggregate 1.0 and the OpenRosa XForms metadata standards >> ( https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema ), I >> recommend using 'id' over 'xmlns' when naming a form. 'id' has the >> advantage that we can eventually extend Aggregate to recognize different >> versions of the same form through the treatment of 'version' and 'uiVersion' >> tags. >> >> Mitch >> >> On Sat, Feb 19, 2011 at 2:26 PM, Andrew Marder wrote: >>> >>> Thanks, Yaw. This is a nice update. I have a few questions. >>> >>> WARNING: choice value [...] is too long; max. suggested length 32 chars >>> Will a choice value with length longer than 32 characters mess up ODK >>> Collect or is this just a suggestion to work nicely with ODK Aggregate and >>> its siblings? >>> >>> Should I use 'xmlns' or 'id' to identify XForms? It seems that Validate >>> and Collect have a preference for 'xmlns' but 'id' will still work. >>> >>> ODK Validate doesn't seem to know about how to take pictures. Maybe I >>> should file this in an issue tracker. >>> Warning: 1 Unrecognized attributes found in Element [upload] and will be >>> ignored: [mediatype] Location: >>> >>> Problem found at nodeset: /html/body/upload >>> With element >>> >>> Warning: 1 Unrecognized attributes found in Element [upload] and will be >>> ignored: [ref] Location: >>> >>> Problem found at nodeset: /html/body/upload >>> With element >>> >>> Thanks again, >>> >>> Andrew >>> >>> On Thu, Feb 17, 2011 at 1:44 PM, Yaw Anokwa wrote: >>> > hello all, >>> > >>> > i just pushed odk validate 1.3 to the website. >>> > >>> > validate 1.3 is a minor release that updates the javarosa library so >>> > it matches the version we are shipping in collect 1.1.5. the change >>> > will ensure you get consistent validation error messages across both >>> > applications. >>> > >>> > yaw >>> > >>> > -- >>> > Post: opendatakit@googlegroups.com >>> > Unsubscribe: opendatakit+unsubscribe@googlegroups.com >>> > Options: http://groups.google.com/group/opendatakit?hl=en >>> > >>> >>> -- >>> Post: opendatakit@googlegroups.com >>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >>> Options: http://groups.google.com/group/opendatakit?hl=en >> >> >> >> -- >> Mitch Sundt >> Software Engineer >> http://www.OpenDataKit.org >> University of Washington >> mitchellsundt@gmail.com >> >> -- >> Post: opendatakit@googlegroups.com >> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >> Options: http://groups.google.com/group/opendatakit?hl=en >> >

to elaborate, in particular mysql supports a rather small total row size.
and if you have a survey with many questions that have long select values,
each column requires a large number of characters (it must be able to
accommodate the longest choice). before you know it, your form has too many
questions to fit into a database row.

··· On Wed, Feb 23, 2011 at 11:41 AM, Yaw Anokwa wrote:

"it is just a suggestion to avoid problems certain popular...
less-than-robust database backends. JR core handles it just fine."
-- drew

this shouldn't affect collect at all. pretty sure it doesn't affect
aggregate or build. i'm assuming mitch, waylon and clint will correct me if
i'm wrong.

On Wed, Feb 23, 2011 at 11:38, Yaw Anokwa yanokwa@gmail.com wrote:

re: choice item length. i think there was a good reason for this, but
i don't remember. i've posted the question to the javarosa-developers
list (
http://groups.google.com/group/javarosa-developers/t/4f53b22c71b18b26)
and will let you know when i know.

On Tue, Feb 22, 2011 at 13:01, Mitch Sundt msundt@cs.washington.edu wrote:

re: xmlns vs. id.

Going forward, with Aggregate 1.0 and the OpenRosa XForms metadata
standards

( https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema), I
recommend using 'id' over 'xmlns' when naming a form. 'id' has the
advantage that we can eventually extend Aggregate to recognize different
versions of the same form through the treatment of 'version' and
'uiVersion'

tags.

Mitch

On Sat, Feb 19, 2011 at 2:26 PM, Andrew Marder < andrew.ei.marder@gmail.com> wrote:

Thanks, Yaw. This is a nice update. I have a few questions.

WARNING: choice value [...] is too long; max. suggested length 32 chars
Will a choice value with length longer than 32 characters mess up ODK
Collect or is this just a suggestion to work nicely with ODK Aggregate
and

its siblings?

Should I use 'xmlns' or 'id' to identify XForms? It seems that Validate
and Collect have a preference for 'xmlns' but 'id' will still work.

ODK Validate doesn't seem to know about how to take pictures. Maybe I
should file this in an issue tracker.
Warning: 1 Unrecognized attributes found in Element [upload] and will
be

ignored: [mediatype] Location:

Problem found at nodeset: /html/body/upload
With element

Warning: 1 Unrecognized attributes found in Element [upload] and will
be

ignored: [ref] Location:

Problem found at nodeset: /html/body/upload
With element

Thanks again,

Andrew

On Thu, Feb 17, 2011 at 1:44 PM, Yaw Anokwa yanokwa@gmail.com wrote:

hello all,

i just pushed odk validate 1.3 to the website.

validate 1.3 is a minor release that updates the javarosa library so
it matches the version we are shipping in collect 1.1.5. the change
will ensure you get consistent validation error messages across both
applications.

yaw

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
http://www.OpenDataKit.org
University of Washington
mitchellsundt@gmail.com

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

I'm currently looking at adding a "length" attribute to tags for
string/select/select1 types which will provide a character-length hint for
the referenced nodeset; this enables more compact construction of the tables
holding the form data, as otherwise Aggregate 1.0 will allocate ~255
characters per field, leading to the aforementioned need to split a form
across multiple database tables due to the limitations of MySQL and/or
Postgres.

The length hint will not prevent strings exceeding that length from being
stored, but those longer strings will generally not be searchable because
they'll be stored in an large-object table (they can be retrieved, but not
pattern-matched against a search string by Aggregate 1.0).

Mitch

··· On Wed, Feb 23, 2011 at 9:43 AM, Drew Roos wrote:

to elaborate, in particular mysql supports a rather small total row size.
and if you have a survey with many questions that have long select values,
each column requires a large number of characters (it must be able to
accommodate the longest choice). before you know it, your form has too many
questions to fit into a database row.

On Wed, Feb 23, 2011 at 11:41 AM, Yaw Anokwa yanokwa@gmail.com wrote:

"it is just a suggestion to avoid problems certain popular...
less-than-robust database backends. JR core handles it just fine."
-- drew

this shouldn't affect collect at all. pretty sure it doesn't affect
aggregate or build. i'm assuming mitch, waylon and clint will correct me
if
i'm wrong.

On Wed, Feb 23, 2011 at 11:38, Yaw Anokwa yanokwa@gmail.com wrote:

re: choice item length. i think there was a good reason for this, but
i don't remember. i've posted the question to the javarosa-developers
list (
http://groups.google.com/group/javarosa-developers/t/4f53b22c71b18b26)
and will let you know when i know.

On Tue, Feb 22, 2011 at 13:01, Mitch Sundt msundt@cs.washington.edu wrote:

re: xmlns vs. id.

Going forward, with Aggregate 1.0 and the OpenRosa XForms metadata
standards

( https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema), I
recommend using 'id' over 'xmlns' when naming a form. 'id' has the
advantage that we can eventually extend Aggregate to recognize
different

versions of the same form through the treatment of 'version' and
'uiVersion'

tags.

Mitch

On Sat, Feb 19, 2011 at 2:26 PM, Andrew Marder < andrew.ei.marder@gmail.com> wrote:

Thanks, Yaw. This is a nice update. I have a few questions.

WARNING: choice value [...] is too long; max. suggested length 32
chars

Will a choice value with length longer than 32 characters mess up ODK
Collect or is this just a suggestion to work nicely with ODK Aggregate
and

its siblings?

Should I use 'xmlns' or 'id' to identify XForms? It seems that
Validate

and Collect have a preference for 'xmlns' but 'id' will still work.

ODK Validate doesn't seem to know about how to take pictures. Maybe I
should file this in an issue tracker.
Warning: 1 Unrecognized attributes found in Element [upload] and will
be

ignored: [mediatype] Location:

Problem found at nodeset: /html/body/upload
With element

Warning: 1 Unrecognized attributes found in Element [upload] and will
be

ignored: [ref] Location:

Problem found at nodeset: /html/body/upload
With element

Thanks again,

Andrew

On Thu, Feb 17, 2011 at 1:44 PM, Yaw Anokwa yanokwa@gmail.com wrote:

hello all,

i just pushed odk validate 1.3 to the website.

validate 1.3 is a minor release that updates the javarosa library so
it matches the version we are shipping in collect 1.1.5. the change
will ensure you get consistent validation error messages across both
applications.

yaw

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
http://www.OpenDataKit.org
University of Washington
mitchellsundt@gmail.com

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
http://www.OpenDataKit.org http://www.opendatakit.org/
University of Washington
mitchellsundt@gmail.com

In MySQL, is a longtext field unsearchable?

Andrew

··· On Wed, Feb 23, 2011 at 1:51 PM, Mitchell Sundt wrote:

I'm currently looking at adding a "length" attribute to tags for
string/select/select1 types which will provide a character-length hint for
the referenced nodeset; this enables more compact construction of the tables
holding the form data, as otherwise Aggregate 1.0 will allocate ~255
characters per field, leading to the aforementioned need to split a form
across multiple database tables due to the limitations of MySQL and/or
Postgres.

The length hint will not prevent strings exceeding that length from being
stored, but those longer strings will generally not be searchable because
they'll be stored in an large-object table (they can be retrieved, but not
pattern-matched against a search string by Aggregate 1.0).

Mitch

On Wed, Feb 23, 2011 at 9:43 AM, Drew Roos droos@dimagi.com wrote:

to elaborate, in particular mysql supports a rather small total row size.
and if you have a survey with many questions that have long select values,
each column requires a large number of characters (it must be able to
accommodate the longest choice). before you know it, your form has too many
questions to fit into a database row.

On Wed, Feb 23, 2011 at 11:41 AM, Yaw Anokwa yanokwa@gmail.com wrote:

"it is just a suggestion to avoid problems certain popular...
less-than-robust database backends. JR core handles it just fine."
-- drew

this shouldn't affect collect at all. pretty sure it doesn't affect
aggregate or build. i'm assuming mitch, waylon and clint will correct me
if
i'm wrong.

On Wed, Feb 23, 2011 at 11:38, Yaw Anokwa yanokwa@gmail.com wrote:

re: choice item length. i think there was a good reason for this, but
i don't remember. i've posted the question to the javarosa-developers
list (
http://groups.google.com/group/javarosa-developers/t/4f53b22c71b18b26)
and will let you know when i know.

On Tue, Feb 22, 2011 at 13:01, Mitch Sundt msundt@cs.washington.edu wrote:

re: xmlns vs. id.

Going forward, with Aggregate 1.0 and the OpenRosa XForms metadata
standards

( https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema), I
recommend using 'id' over 'xmlns' when naming a form. 'id' has the
advantage that we can eventually extend Aggregate to recognize
different

versions of the same form through the treatment of 'version' and
'uiVersion'

tags.

Mitch

On Sat, Feb 19, 2011 at 2:26 PM, Andrew Marder < andrew.ei.marder@gmail.com> wrote:

Thanks, Yaw. This is a nice update. I have a few questions.

WARNING: choice value [...] is too long; max. suggested length 32
chars

Will a choice value with length longer than 32 characters mess up ODK
Collect or is this just a suggestion to work nicely with ODK
Aggregate and

its siblings?

Should I use 'xmlns' or 'id' to identify XForms? It seems that
Validate

and Collect have a preference for 'xmlns' but 'id' will still work.

ODK Validate doesn't seem to know about how to take pictures. Maybe I
should file this in an issue tracker.
Warning: 1 Unrecognized attributes found in Element [upload] and will
be

ignored: [mediatype] Location:

Problem found at nodeset: /html/body/upload
With element

Warning: 1 Unrecognized attributes found in Element [upload] and will
be

ignored: [ref] Location:

Problem found at nodeset: /html/body/upload
With element

Thanks again,

Andrew

On Thu, Feb 17, 2011 at 1:44 PM, Yaw Anokwa yanokwa@gmail.com wrote:

hello all,

i just pushed odk validate 1.3 to the website.

validate 1.3 is a minor release that updates the javarosa library
so

it matches the version we are shipping in collect 1.1.5. the change
will ensure you get consistent validation error messages across
both

applications.

yaw

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
http://www.OpenDataKit.org
University of Washington
mitchellsundt@gmail.com

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
http://www.OpenDataKit.org http://www.opendatakit.org/
University of Washington
mitchellsundt@gmail.com

There are native limitations.

MySQL only uses the first 1024 characters for sorting, for example (see
http://dev.mysql.com/doc/refman/5.0/en/blob.html ).

Google's BigTable doesn't index long text fields, so querying and filtering
are not natively supported (see
http://code.google.com/appengine/docs/java/datastore/entities.html#Properties_and_Value_Types)

Aggregate 1.0 works around this by storing the first ~250 characters in a
searchable string, then storing the full text in these large text storage
areas. So we don't loose data. However, we only support searching on the
first ~250 characters through the Aggregate 1.0 user interface. This
originated as a BigTable limitation, but is retained in the implementation
largely because of the added code we'd have to write to handle searching
beyond that.

When I get the "length" attribute implemented, it would define the length
limit instead of the generic "~250" character limit. With the caveat that
Google BigTable has a hard cap of 500 characters.

Mitch

··· On Wed, Feb 23, 2011 at 10:55 AM, Andrew Marder wrote:

In MySQL, is a longtext field unsearchable?

Andrew

On Wed, Feb 23, 2011 at 1:51 PM, Mitchell Sundt msundt@cs.washington.eduwrote:

I'm currently looking at adding a "length" attribute to tags for
string/select/select1 types which will provide a character-length hint for
the referenced nodeset; this enables more compact construction of the tables
holding the form data, as otherwise Aggregate 1.0 will allocate ~255
characters per field, leading to the aforementioned need to split a form
across multiple database tables due to the limitations of MySQL and/or
Postgres.

The length hint will not prevent strings exceeding that length from being
stored, but those longer strings will generally not be searchable because
they'll be stored in an large-object table (they can be retrieved, but not
pattern-matched against a search string by Aggregate 1.0).

Mitch

On Wed, Feb 23, 2011 at 9:43 AM, Drew Roos droos@dimagi.com wrote:

to elaborate, in particular mysql supports a rather small total row size.
and if you have a survey with many questions that have long select values,
each column requires a large number of characters (it must be able to
accommodate the longest choice). before you know it, your form has too many
questions to fit into a database row.

On Wed, Feb 23, 2011 at 11:41 AM, Yaw Anokwa yanokwa@gmail.com wrote:

"it is just a suggestion to avoid problems certain popular...
less-than-robust database backends. JR core handles it just fine."
-- drew

this shouldn't affect collect at all. pretty sure it doesn't affect
aggregate or build. i'm assuming mitch, waylon and clint will correct me
if
i'm wrong.

On Wed, Feb 23, 2011 at 11:38, Yaw Anokwa yanokwa@gmail.com wrote:

re: choice item length. i think there was a good reason for this, but
i don't remember. i've posted the question to the javarosa-developers
list (
http://groups.google.com/group/javarosa-developers/t/4f53b22c71b18b26)
and will let you know when i know.

On Tue, Feb 22, 2011 at 13:01, Mitch Sundt msundt@cs.washington.edu wrote:

re: xmlns vs. id.

Going forward, with Aggregate 1.0 and the OpenRosa XForms metadata
standards

(
https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema ),
I

recommend using 'id' over 'xmlns' when naming a form. 'id' has the
advantage that we can eventually extend Aggregate to recognize
different

versions of the same form through the treatment of 'version' and
'uiVersion'

tags.

Mitch

On Sat, Feb 19, 2011 at 2:26 PM, Andrew Marder < andrew.ei.marder@gmail.com> wrote:

Thanks, Yaw. This is a nice update. I have a few questions.

WARNING: choice value [...] is too long; max. suggested length 32
chars

Will a choice value with length longer than 32 characters mess up
ODK

Collect or is this just a suggestion to work nicely with ODK
Aggregate and

its siblings?

Should I use 'xmlns' or 'id' to identify XForms? It seems that
Validate

and Collect have a preference for 'xmlns' but 'id' will still work.

ODK Validate doesn't seem to know about how to take pictures. Maybe
I

should file this in an issue tracker.
Warning: 1 Unrecognized attributes found in Element [upload] and
will be

ignored: [mediatype] Location:

Problem found at nodeset: /html/body/upload
With element

Warning: 1 Unrecognized attributes found in Element [upload] and
will be

ignored: [ref] Location:

Problem found at nodeset: /html/body/upload
With element

Thanks again,

Andrew

On Thu, Feb 17, 2011 at 1:44 PM, Yaw Anokwa yanokwa@gmail.com wrote:

hello all,

i just pushed odk validate 1.3 to the website.

validate 1.3 is a minor release that updates the javarosa library
so

it matches the version we are shipping in collect 1.1.5. the
change

will ensure you get consistent validation error messages across
both

applications.

yaw

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
http://www.OpenDataKit.org
University of Washington
mitchellsundt@gmail.com

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
http://www.OpenDataKit.org http://www.opendatakit.org/
University of Washington
mitchellsundt@gmail.com

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer


University of Washington
mitchellsundt@gmail.com

Very interesting, thanks for edumucating me. It's good to hear about these
limitations so I have an idea of what's going to bite me down the road.

Andrew

··· On Wed, Feb 23, 2011 at 2:40 PM, Mitch Sundt wrote:

There are native limitations.

MySQL only uses the first 1024 characters for sorting, for example (see
http://dev.mysql.com/doc/refman/5.0/en/blob.html ).

Google's BigTable doesn't index long text fields, so querying and filtering
are not natively supported (see
http://code.google.com/appengine/docs/java/datastore/entities.html#Properties_and_Value_Types)

Aggregate 1.0 works around this by storing the first ~250 characters in a
searchable string, then storing the full text in these large text storage
areas. So we don't loose data. However, we only support searching on the
first ~250 characters through the Aggregate 1.0 user interface. This
originated as a BigTable limitation, but is retained in the implementation
largely because of the added code we'd have to write to handle searching
beyond that.

When I get the "length" attribute implemented, it would define the length
limit instead of the generic "~250" character limit. With the caveat that
Google BigTable has a hard cap of 500 characters.

Mitch

On Wed, Feb 23, 2011 at 10:55 AM, Andrew Marder < andrew.ei.marder@gmail.com> wrote:

In MySQL, is a longtext field unsearchable?

Andrew

On Wed, Feb 23, 2011 at 1:51 PM, Mitchell Sundt <msundt@cs.washington.edu wrote:

I'm currently looking at adding a "length" attribute to tags for
string/select/select1 types which will provide a character-length hint for
the referenced nodeset; this enables more compact construction of the tables
holding the form data, as otherwise Aggregate 1.0 will allocate ~255
characters per field, leading to the aforementioned need to split a form
across multiple database tables due to the limitations of MySQL and/or
Postgres.

The length hint will not prevent strings exceeding that length from being
stored, but those longer strings will generally not be searchable because
they'll be stored in an large-object table (they can be retrieved, but not
pattern-matched against a search string by Aggregate 1.0).

Mitch

On Wed, Feb 23, 2011 at 9:43 AM, Drew Roos droos@dimagi.com wrote:

to elaborate, in particular mysql supports a rather small total row
size. and if you have a survey with many questions that have long select
values, each column requires a large number of characters (it must be able
to accommodate the longest choice). before you know it, your form has too
many questions to fit into a database row.

On Wed, Feb 23, 2011 at 11:41 AM, Yaw Anokwa yanokwa@gmail.com wrote:

"it is just a suggestion to avoid problems certain popular...
less-than-robust database backends. JR core handles it just fine."
-- drew

this shouldn't affect collect at all. pretty sure it doesn't affect
aggregate or build. i'm assuming mitch, waylon and clint will correct
me if
i'm wrong.

On Wed, Feb 23, 2011 at 11:38, Yaw Anokwa yanokwa@gmail.com wrote:

re: choice item length. i think there was a good reason for this, but
i don't remember. i've posted the question to the javarosa-developers
list (
http://groups.google.com/group/javarosa-developers/t/4f53b22c71b18b26)
and will let you know when i know.

On Tue, Feb 22, 2011 at 13:01, Mitch Sundt msundt@cs.washington.edu wrote:

re: xmlns vs. id.

Going forward, with Aggregate 1.0 and the OpenRosa XForms metadata
standards

(
https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema ),
I

recommend using 'id' over 'xmlns' when naming a form. 'id' has the
advantage that we can eventually extend Aggregate to recognize
different

versions of the same form through the treatment of 'version' and
'uiVersion'

tags.

Mitch

On Sat, Feb 19, 2011 at 2:26 PM, Andrew Marder < andrew.ei.marder@gmail.com> wrote:

Thanks, Yaw. This is a nice update. I have a few questions.

WARNING: choice value [...] is too long; max. suggested length 32
chars

Will a choice value with length longer than 32 characters mess up
ODK

Collect or is this just a suggestion to work nicely with ODK
Aggregate and

its siblings?

Should I use 'xmlns' or 'id' to identify XForms? It seems that
Validate

and Collect have a preference for 'xmlns' but 'id' will still work.

ODK Validate doesn't seem to know about how to take pictures. Maybe
I

should file this in an issue tracker.
Warning: 1 Unrecognized attributes found in Element [upload] and
will be

ignored: [mediatype] Location:

Problem found at nodeset: /html/body/upload
With element

Warning: 1 Unrecognized attributes found in Element [upload] and
will be

ignored: [ref] Location:

Problem found at nodeset: /html/body/upload
With element

Thanks again,

Andrew

On Thu, Feb 17, 2011 at 1:44 PM, Yaw Anokwa yanokwa@gmail.com wrote:

hello all,

i just pushed odk validate 1.3 to the website.

validate 1.3 is a minor release that updates the javarosa library
so

it matches the version we are shipping in collect 1.1.5. the
change

will ensure you get consistent validation error messages across
both

applications.

yaw

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
http://www.OpenDataKit.org
University of Washington
mitchellsundt@gmail.com

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
http://www.OpenDataKit.org http://www.opendatakit.org/
University of Washington
mitchellsundt@gmail.com

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
http://www.OpenDataKit.org
University of Washington
mitchellsundt@gmail.com

To further clarify Aggregate 1.0 removes mysql's row size limitation
by automatically creating multiple tables to split the rows if needed.
Mitch's comments about the search able portion of a field/item are
correct. Aggregate can allow many long columns and avoid row size
limitations; however, right now you may not be able to search the long
text in a query.

··· On Wed, Feb 23, 2011 at 11:48 AM, Andrew Marder wrote: > Very interesting, thanks for edumucating me. It's good to hear about these > limitations so I have an idea of what's going to bite me down the road. > Andrew > > On Wed, Feb 23, 2011 at 2:40 PM, Mitch Sundt wrote: >> >> There are native limitations. >> >> MySQL only uses the first 1024 characters for sorting, for example (see >> http://dev.mysql.com/doc/refman/5.0/en/blob.html ). >> >> Google's BigTable doesn't index long text fields, so querying and >> filtering are not natively supported (see >> http://code.google.com/appengine/docs/java/datastore/entities.html#Properties_and_Value_Types >> ) >> >> Aggregate 1.0 works around this by storing the first ~250 characters in a >> searchable string, then storing the full text in these large text storage >> areas. So we don't loose data. However, we only support searching on the >> first ~250 characters through the Aggregate 1.0 user interface. This >> originated as a BigTable limitation, but is retained in the implementation >> largely because of the added code we'd have to write to handle searching >> beyond that. >> >> When I get the "length" attribute implemented, it would define the length >> limit instead of the generic "~250" character limit. With the caveat that >> Google BigTable has a hard cap of 500 characters. >> >> Mitch >> >> On Wed, Feb 23, 2011 at 10:55 AM, Andrew Marder wrote: >>> >>> In MySQL, is a longtext field unsearchable? >>> Andrew >>> >>> On Wed, Feb 23, 2011 at 1:51 PM, Mitchell Sundt wrote: >>>> >>>> I'm currently looking at adding a "length" attribute to tags for >>>> string/select/select1 types which will provide a character-length hint for >>>> the referenced nodeset; this enables more compact construction of the tables >>>> holding the form data, as otherwise Aggregate 1.0 will allocate ~255 >>>> characters per field, leading to the aforementioned need to split a form >>>> across multiple database tables due to the limitations of MySQL and/or >>>> Postgres. >>>> >>>> The length hint will not prevent strings exceeding that length from >>>> being stored, but those longer strings will generally not be searchable >>>> because they'll be stored in an large-object table (they can be retrieved, >>>> but not pattern-matched against a search string by Aggregate 1.0). >>>> >>>> Mitch >>>> >>>> On Wed, Feb 23, 2011 at 9:43 AM, Drew Roos wrote: >>>>> >>>>> to elaborate, in particular mysql supports a rather small total row >>>>> size. and if you have a survey with many questions that have long select >>>>> values, each column requires a large number of characters (it must be able >>>>> to accommodate the longest choice). before you know it, your form has too >>>>> many questions to fit into a database row. >>>>> >>>>> On Wed, Feb 23, 2011 at 11:41 AM, Yaw Anokwa wrote: >>>>>> >>>>>> "it is just a suggestion to avoid problems certain popular... >>>>>> less-than-robust database backends. JR core handles it just fine." >>>>>> -- drew >>>>>> >>>>>> this shouldn't affect collect at all. pretty sure it doesn't affect >>>>>> aggregate or build. i'm assuming mitch, waylon and clint will correct >>>>>> me if >>>>>> i'm wrong. >>>>>> >>>>>> On Wed, Feb 23, 2011 at 11:38, Yaw Anokwa wrote: >>>>>> > re: choice item length. i think there was a good reason for this, >>>>>> > but >>>>>> > i don't remember. i've posted the question to the >>>>>> > javarosa-developers >>>>>> > list >>>>>> > (http://groups.google.com/group/javarosa-developers/t/4f53b22c71b18b26) >>>>>> > and will let you know when i know. >>>>>> > >>>>>> > On Tue, Feb 22, 2011 at 13:01, Mitch Sundt wrote: >>>>>> >> re: xmlns vs. id. >>>>>> >> >>>>>> >> Going forward, with Aggregate 1.0 and the OpenRosa XForms metadata >>>>>> >> standards >>>>>> >> ( >>>>>> >> https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema ), I >>>>>> >> recommend using 'id' over 'xmlns' when naming a form. 'id' has the >>>>>> >> advantage that we can eventually extend Aggregate to recognize >>>>>> >> different >>>>>> >> versions of the same form through the treatment of 'version' and >>>>>> >> 'uiVersion' >>>>>> >> tags. >>>>>> >> >>>>>> >> Mitch >>>>>> >> >>>>>> >> On Sat, Feb 19, 2011 at 2:26 PM, Andrew Marder wrote: >>>>>> >>> >>>>>> >>> Thanks, Yaw. This is a nice update. I have a few questions. >>>>>> >>> >>>>>> >>> WARNING: choice value [...] is too long; max. suggested length 32 >>>>>> >>> chars >>>>>> >>> Will a choice value with length longer than 32 characters mess up >>>>>> >>> ODK >>>>>> >>> Collect or is this just a suggestion to work nicely with ODK >>>>>> >>> Aggregate and >>>>>> >>> its siblings? >>>>>> >>> >>>>>> >>> Should I use 'xmlns' or 'id' to identify XForms? It seems that >>>>>> >>> Validate >>>>>> >>> and Collect have a preference for 'xmlns' but 'id' will still >>>>>> >>> work. >>>>>> >>> >>>>>> >>> ODK Validate doesn't seem to know about how to take pictures. >>>>>> >>> Maybe I >>>>>> >>> should file this in an issue tracker. >>>>>> >>> Warning: 1 Unrecognized attributes found in Element [upload] and >>>>>> >>> will be >>>>>> >>> ignored: [mediatype] Location: >>>>>> >>> >>>>>> >>> Problem found at nodeset: /html/body/upload >>>>>> >>> With element >>>>>> >>> >>>>>> >>> Warning: 1 Unrecognized attributes found in Element [upload] and >>>>>> >>> will be >>>>>> >>> ignored: [ref] Location: >>>>>> >>> >>>>>> >>> Problem found at nodeset: /html/body/upload >>>>>> >>> With element >>>>>> >>> >>>>>> >>> Thanks again, >>>>>> >>> >>>>>> >>> Andrew >>>>>> >>> >>>>>> >>> On Thu, Feb 17, 2011 at 1:44 PM, Yaw Anokwa wrote: >>>>>> >>> > hello all, >>>>>> >>> > >>>>>> >>> > i just pushed odk validate 1.3 to the website. >>>>>> >>> > >>>>>> >>> > validate 1.3 is a minor release that updates the javarosa >>>>>> >>> > library so >>>>>> >>> > it matches the version we are shipping in collect 1.1.5. the >>>>>> >>> > change >>>>>> >>> > will ensure you get consistent validation error messages across >>>>>> >>> > both >>>>>> >>> > applications. >>>>>> >>> > >>>>>> >>> > yaw >>>>>> >>> > >>>>>> >>> > -- >>>>>> >>> > Post: opendatakit@googlegroups.com >>>>>> >>> > Unsubscribe: opendatakit+unsubscribe@googlegroups.com >>>>>> >>> > Options: http://groups.google.com/group/opendatakit?hl=en >>>>>> >>> > >>>>>> >>> >>>>>> >>> -- >>>>>> >>> Post: opendatakit@googlegroups.com >>>>>> >>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >>>>>> >>> Options: http://groups.google.com/group/opendatakit?hl=en >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> -- >>>>>> >> Mitch Sundt >>>>>> >> Software Engineer >>>>>> >> http://www.OpenDataKit.org >>>>>> >> University of Washington >>>>>> >> mitchellsundt@gmail.com >>>>>> >> >>>>>> >> -- >>>>>> >> Post: opendatakit@googlegroups.com >>>>>> >> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >>>>>> >> Options: http://groups.google.com/group/opendatakit?hl=en >>>>>> >> >>>>>> > >>>>>> >>>>>> -- >>>>>> Post: opendatakit@googlegroups.com >>>>>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >>>>>> Options: http://groups.google.com/group/opendatakit?hl=en >>>>> >>>> >>>> >>>> >>>> -- >>>> Mitch Sundt >>>> Software Engineer >>>> http://www.OpenDataKit.org >>>> University of Washington >>>> mitchellsundt@gmail.com >>>> >>>> >>> >>> -- >>> Post: opendatakit@googlegroups.com >>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >>> Options: http://groups.google.com/group/opendatakit?hl=en >> >> >> >> -- >> Mitch Sundt >> Software Engineer >> http://www.OpenDataKit.org >> University of Washington >> mitchellsundt@gmail.com > > -- > Post: opendatakit@googlegroups.com > Unsubscribe: opendatakit+unsubscribe@googlegroups.com > Options: http://groups.google.com/group/opendatakit?hl=en >

How real a problem is this? Trying to touch type 250+ character fields would
be very taxing and speaking for myself I'd likely run down my evo battery on
the first long field.

-steve-

-- Painfully slowly typed on my htc EVO --

To further clarify Aggregate 1.0 removes mysql's row size limitation
by automatically creating multiple tables to split the rows if needed.
Mitch's comments about the search able portion of a field/item are
correct. Aggregate can allow many long columns and avoid row size
limitations; however, right now you may not be able to search the long
text in a query.

Very interesting, thanks for edumucating me. It's good to hear about
these

limitations so I have an idea of what's going to bite me down the road.
Andrew

There are native limitations.

MySQL only uses the first 1024 characters for sorting, for example (see
http://dev.mysql.com/doc/refman/5.0/en/blob.html ).

Google's BigTable doesn't index long text fields, so querying and
filtering are not natively supported (see

http://code.google.com/appengine/docs/java/datastore/entities.html#Properties_and_Value_Types

)

Aggregate 1.0 works around this by storing the first ~250 characters in
a

searchable string, then storing the full text in these large text
storage

areas. So we don't loose data. However, we only support searching on
the

first ~250 characters through the Aggregate 1.0 user interface. This
originated as a BigTable limitation, but is retained in the
implementation

largely because of the added code we'd have to write to handle searching
beyond that.

When I get the "length" attribute implemented, it would define the
length

limit instead of the generic "~250" character limit. With the caveat
that

Google BigTable has a hard cap of 500 characters.

Mitch

In MySQL, is a longtext field unsearchable?
Andrew

I'm currently looking at adding a "length" attribute to tags
for

string/select/select1 types which will provide a character-length hint
for

the referenced nodeset; this enables more compact construction of the
tables

holding the form data, as otherwise Aggregate 1.0 will allocate ~255
characters per field, leading to the aforementioned need to split a
form

across multiple database tables due to the limitations of MySQL and/or
Postgres.

The length hint will not prevent strings exceeding that length from
being stored, but those longer strings will generally not be
searchable

because they'll be stored in an large-object table (they can be
retrieved,

but not pattern-matched against a search string by Aggregate 1.0).

Mitch

to elaborate, in particular mysql supports a rather small total row
size. and if you have a survey with many questions that have long
select

values, each column requires a large number of characters (it must be
able

to accommodate the longest choice). before you know it, your form has
too

many questions to fit into a database row.

"it is just a suggestion to avoid problems certain popular...
less-than-robust database backends. JR core handles it just fine."
-- drew

this shouldn't affect collect at all. pretty sure it doesn't affect
aggregate or build. i'm assuming mitch, waylon and clint will
correct

me if
i'm wrong.

re: choice item length. i think there was a good reason for this,
but
i don't remember. i've posted the question to the
javarosa-developers
list
(
http://groups.google.com/group/javarosa-developers/t/4f53b22c71b18b26)

and will let you know when i know.

re: xmlns vs. id.

Going forward, with Aggregate 1.0 and the OpenRosa XForms
metadata

standards
(

https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema ), I

recommend using 'id' over 'xmlns' when naming a form. 'id' has
the

advantage that we can eventually extend Aggregate to recognize
different
versions of the same form through the treatment of 'version' and
'uiVersion'
tags.

Mitch

Thanks, Yaw. This is a nice update. I have a few questions.

WARNING: choice value [...] is too long; max. suggested length
32

chars
Will a choice value with length longer than 32 characters mess
up

ODK
Collect or is this just a suggestion to work nicely with ODK
Aggregate and
its siblings?

Should I use 'xmlns' or 'id' to identify XForms? It seems that
Validate
and Collect have a preference for 'xmlns' but 'id' will still
work.

ODK Validate doesn't seem to know about how to take pictures.
Maybe I
should file this in an issue tracker.
Warning: 1 Unrecognized attributes found in Element [upload] and
will be
ignored: [mediatype] Location:

Problem found at nodeset: /html/body/upload
With element

Warning: 1 Unrecognized attributes found in Element [upload] and
will be
ignored: [ref] Location:

Problem found at nodeset: /html/body/upload
With element

Thanks again,

Andrew

hello all,

i just pushed odk validate 1.3 to the website.

validate 1.3 is a minor release that updates the javarosa
library so
it matches the version we are shipping in collect 1.1.5. the
change
will ensure you get consistent validation error messages
across

··· On Feb 23, 2011 3:07 PM, "W. Brunette" wrote: > On Wed, Feb 23, 2011 at 11:48 AM, Andrew Marder wrote: >> On Wed, Feb 23, 2011 at 2:40 PM, Mitch Sundt wrote: >>> On Wed, Feb 23, 2011 at 10:55 AM, Andrew Marder wrote: >>>> On Wed, Feb 23, 2011 at 1:51 PM, Mitchell Sundt wrote: >>>>> On Wed, Feb 23, 2011 at 9:43 AM, Drew Roos wrote: >>>>>> On Wed, Feb 23, 2011 at 11:41 AM, Yaw Anokwa wrote: >>>>>>> On Wed, Feb 23, 2011 at 11:38, Yaw Anokwa wrote: >>>>>>> > On Tue, Feb 22, 2011 at 13:01, Mitch Sundt wrote: >>>>>>> >> On Sat, Feb 19, 2011 at 2:26 PM, Andrew Marder wrote: >>>>>>> >>> On Thu, Feb 17, 2011 at 1:44 PM, Yaw Anokwa wrote: >>>>>>> >>> > both >>>>>>> >>> > applications. >>>>>>> >>> > >>>>>>> >>> > yaw >>>>>>> >>> > >>>>>>> >>> > -- >>>>>>> >>> > Post: opendatakit@googlegroups.com >>>>>>> >>> > Unsubscribe: opendatakit+unsubscribe@googlegroups.com >>>>>>> >>> > Options: http://groups.google.com/group/opendatakit?hl=en >>>>>>> >>> > >>>>>>> >>> >>>>>>> >>> -- >>>>>>> >>> Post: opendatakit@googlegroups.com >>>>>>> >>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >>>>>>> >>> Options: http://groups.google.com/group/opendatakit?hl=en >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> -- >>>>>>> >> Mitch Sundt >>>>>>> >> Software Engineer >>>>>>> >> http://www.OpenDataKit.org >>>>>>> >> University of Washington >>>>>>> >> mitchellsundt@gmail.com >>>>>>> >> >>>>>>> >> -- >>>>>>> >> Post: opendatakit@googlegroups.com >>>>>>> >> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >>>>>>> >> Options: http://groups.google.com/group/opendatakit?hl=en >>>>>>> >> >>>>>>> > >>>>>>> >>>>>>> -- >>>>>>> Post: opendatakit@googlegroups.com >>>>>>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >>>>>>> Options: http://groups.google.com/group/opendatakit?hl=en >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Mitch Sundt >>>>> Software Engineer >>>>> http://www.OpenDataKit.org >>>>> University of Washington >>>>> mitchellsundt@gmail.com >>>>> >>>>> >>>> >>>> -- >>>> Post: opendatakit@googlegroups.com >>>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >>>> Options: http://groups.google.com/group/opendatakit?hl=en >>> >>> >>> >>> -- >>> Mitch Sundt >>> Software Engineer >>> http://www.OpenDataKit.org >>> University of Washington >>> mitchellsundt@gmail.com >> >> -- >> Post: opendatakit@googlegroups.com >> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >> Options: http://groups.google.com/group/opendatakit?hl=en >> > > -- > Post: opendatakit@googlegroups.com > Unsubscribe: opendatakit+unsubscribe@googlegroups.com > Options: http://groups.google.com/group/opendatakit?hl=en