We are using ODK Aggregate v1.4 with Collect. Is there a way for me to make minor changes to a form (fix a typo) without incrementing the form's version on Aggregate. We are trying to avoid having too many versions of a form on ODK Aggregate because it always ends up being messy when we start data analysis.
I've looked at Aggregate's code (v1.4) with the intention of adding this functionality (if it does not exist).
The method compareXml in opendatakit.aggregate/src/main/java/org/opendatakit/aggregate/parser/FormParserForJavaRosa.java checks for whether incomingParser.rootElementDefn.versionString is null to determine if the incoming form has a similar version to the already existing xml form but is different. Someone please tell me if I am barking on the wrong tree or explain to me the logic if this is actually true
Jason,
You're looking in the right place, though you're probably posting to the
wrong group. The opendatakit-developers would be better.
In any case, yes, compareXml() is deeply involved in this stuff. You seem
to want to allow non-DB-changing form updates without requiring that the
version be incremented. However, note that this would make it impossible to
tell, when you look at the version on a particular device, which "real"
version it is. By allowing different versions of a form to share the same
version number, you may turn out to hurt more than you help.
You say that "it always ends up being messy when we start data analysis"
when you increment the version number, but I don't see why that is. With at
least the SurveyCTO suite, data remains fully compatible across
form-version updates (such as typo fixes, changes to constraints, etc.),
and so there is no messiness -- and I thought that the same was true for
the core ODK suite. Maybe describe the messiness you're seeing and somebody
can help you work around that while staying within the off-the-shelf
functionality.
Best,
Chris
···
On Fri, Jan 24, 2014 at 8:44 AM, wrote:
We are using ODK Aggregate v1.4 with Collect. Is there a way for me to
make minor changes to a form (fix a typo) without incrementing the form's
version on Aggregate. We are trying to avoid having too many versions of a
form on ODK Aggregate because it always ends up being messy when we start
data analysis.
I've looked at Aggregate's code (v1.4) with the intention of adding this
functionality (if it does not exist).
The method compareXml in
opendatakit.aggregate/src/main/java/org/opendatakit/aggregate/parser/FormParserForJavaRosa.java
checks for whether incomingParser.rootElementDefn.versionString is null to
determine if the incoming form has a similar version to the already
existing xml form but is different. Someone please tell me if I am barking
on the wrong tree or explain to me the logic if this is actually true
--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en
You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
I think you may be confused. 'version' is exactly what you do want to use.
There are two values you can use to identify a form. On the XLS
spreadheet's settings tab, these are:
form_id -- must be changed when the data model changes (when you add or
remove a prompt, or change a prompt from a string to an integer or decimal
or multiple-choice value).
version -- this is available to track changes such as typo corrections,
wording revisions, additional language translations, etc.
i.e., the 'version' setting is exactly what you do want to use.
If you leave the form_id unchanged, and change the version, then you can
upload the new form XML to ODK Aggregate. The new form will replace the old
one on ODK Aggregate (you will no longer be able to download the older
form), and the new and old form submissions will be submitted into the same
submissions table. The version of the form used when the survey was
finalized is available as metadata on each submission.
Note that the 'version' string must always compare alphabetically greater
than what preceded it in order for ODK Aggregate to accept the upload of a
new form definition. This is to prevent inadvertent mix-ups from
confounding your data collection efforts.
We recommend a format:
yyyymmddhh or something like that. I.e,,
2014012409 -- form version of Jan 24, 2014 at 9 am.
Mitch
···
On Fri, Jan 24, 2014 at 10:04 AM, Christopher Robert wrote:
Jason,
You're looking in the right place, though you're probably posting to the
wrong group. The opendatakit-developers would be better.
In any case, yes, compareXml() is deeply involved in this stuff. You seem
to want to allow non-DB-changing form updates without requiring that the
version be incremented. However, note that this would make it impossible to
tell, when you look at the version on a particular device, which "real"
version it is. By allowing different versions of a form to share the same
version number, you may turn out to hurt more than you help.
You say that "it always ends up being messy when we start data analysis"
when you increment the version number, but I don't see why that is. With at
least the SurveyCTO suite, data remains fully compatible across
form-version updates (such as typo fixes, changes to constraints, etc.),
and so there is no messiness -- and I thought that the same was true for
the core ODK suite. Maybe describe the messiness you're seeing and somebody
can help you work around that while staying within the off-the-shelf
functionality.
Best,
Chris
On Fri, Jan 24, 2014 at 8:44 AM, jasonrogena@gmail.com wrote:
We are using ODK Aggregate v1.4 with Collect. Is there a way for me to
make minor changes to a form (fix a typo) without incrementing the form's
version on Aggregate. We are trying to avoid having too many versions of a
form on ODK Aggregate because it always ends up being messy when we start
data analysis.
I've looked at Aggregate's code (v1.4) with the intention of adding this
functionality (if it does not exist).
The method compareXml in
opendatakit.aggregate/src/main/java/org/opendatakit/aggregate/parser/FormParserForJavaRosa.java
checks for whether incomingParser.rootElementDefn.versionString is null to
determine if the incoming form has a similar version to the already
existing xml form but is different. Someone please tell me if I am barking
on the wrong tree or explain to me the logic if this is actually true
--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en
You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en
You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
Thanks man, I hadn't considered this: *However, note that this would make
it impossible to tell, when you look at the version on a particular device,
which "real" version it is. *We actually use an inhouse tool that converts
exported submissions from Aggregate into excel sheets.
Thanks again,
Jason
···
On Friday, 24 January 2014 21:04:27 UTC+3, Christopher Robert wrote:
>
> Jason,
>
> You're looking in the right place, though you're probably posting to the
> wrong group. The opendatakit-developers would be better.
>
> In any case, yes, compareXml() is deeply involved in this stuff. You seem
> to want to allow non-DB-changing form updates without requiring that the
> version be incremented. However, note that this would make it impossible to
> tell, when you look at the version on a particular device, which "real"
> version it is. By allowing different versions of a form to share the same
> version number, you may turn out to hurt more than you help.
>
> You say that "it always ends up being messy when we start data analysis"
> when you increment the version number, but I don't see why that is. With at
> least the SurveyCTO suite, data remains fully compatible across
> form-version updates (such as typo fixes, changes to constraints, etc.),
> and so there is no messiness -- and I thought that the same was true for
> the core ODK suite. Maybe describe the messiness you're seeing and somebody
> can help you work around that while staying within the off-the-shelf
> functionality.
>
> Best,
>
> Chris
>
>
>
> On Fri, Jan 24, 2014 at 8:44 AM, <jason...@gmail.com > wrote:
>
>> We are using ODK Aggregate v1.4 with Collect. Is there a way for me to
>> make minor changes to a form (fix a typo) without incrementing the form's
>> version on Aggregate. We are trying to avoid having too many versions of a
>> form on ODK Aggregate because it always ends up being messy when we start
>> data analysis.
>>
>> I've looked at Aggregate's code (v1.4) with the intention of adding this
>> functionality (if it does not exist).
>>
>> The method compareXml in
>> opendatakit.aggregate/src/main/java/org/opendatakit/aggregate/parser/FormParserForJavaRosa.java
>> checks for whether incomingParser.rootElementDefn.versionString is null to
>> determine if the incoming form has a similar version to the already
>> existing xml form but is different. Someone please tell me if I am barking
>> on the wrong tree or explain to me the logic if this is actually true
>>
>> --
>> --
>> Post: opend...@googlegroups.com
>> Unsubscribe: opendatakit...@googlegroups.com
>> Options: http://groups.google.com/group/opendatakit?hl=en
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "ODK Community" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to opendatakit...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>