Request for comments: html status code for "survey no longer active" - is 406 appropriate?

In the interest of keeping various versions of OpenRosa compatible with
each other, I am asking for input from this group.

I am in the process of modifying formhub so that survey administrators can
switch a survey to "inactive" status at a point in time. This is
considered very important when a survey may be replaced by a newer version
to insure that data collectors do not use the newly-obsolete version. An
immediate error message when they try to submit the obsolescent data will
save a lot of trouble and misunderstanding.

I am searching for the best status code to send from the server when
rejecting the data. Clearly the 400 range is called for, an indication that
something serious is wrong with the data coming from the client. My best
guess is 406 (Not Acceptable).

The reasonable alternatives seem to be:
406 -- Not Acceptable
410 -- Gone
412 -- Precondition Failed
422 -- Unprocessable Entity

My prototype code sends error message text with the html response, but ODK
Collect (v1.4) does not display it -- only the number and description of
the status code.

Is this a good design? What changes should I consider?

ODK Aggregate returns a 404 -- not found.

I'm concerned you are introducing a new concept into the form processing
mechanism.

I would like formHub to match the interaction semantics of ODK Aggregate:

'form_id' designates a set of submissions that can be folded together into
one result set.

If you need to make changes that cannot be folded together, you should use
a different 'form_id'.

For a given form_id, the 'version' string is used to designate and track
the version of the form.

··· ----------------- It is then up to you what you do with different versions of the form, and how you determine what the threshold is beyond which you require a different form_id be used.

Because data collectors can sync and have different versions of a form on
their devices, it doesn't seem reasonable to reject submissions from older
versions of the same form.

I am not clear whether you are trying to invalidate already-collected
submissions, or introduce re-use of a form-id for incompatible data.

Mitch

On Thu, Feb 20, 2014 at 3:59 AM, Vernon D. Cole vernondcole@gmail.comwrote:

In the interest of keeping various versions of OpenRosa compatible with
each other, I am asking for input from this group.

I am in the process of modifying formhub so that survey administrators can
switch a survey to "inactive" status at a point in time. This is
considered very important when a survey may be replaced by a newer version
to insure that data collectors do not use the newly-obsolete version. An
immediate error message when they try to submit the obsolescent data will
save a lot of trouble and misunderstanding.

I am searching for the best status code to send from the server when
rejecting the data. Clearly the 400 range is called for, an indication that
something serious is wrong with the data coming from the client. My best
guess is 406 (Not Acceptable).

The reasonable alternatives seem to be:
406 -- Not Acceptable
410 -- Gone
412 -- Precondition Failed
422 -- Unprocessable Entity

My prototype code sends error message text with the html response, but ODK
Collect (v1.4) does not display it -- only the number and description of
the status code.

Is this a good design? What changes should I consider?

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

Right. I understand that the form_id must change when the form is
re-designed. This is to catch (and reject) continued use of an old
form. Yes, the survey administrators do want to invalidate submissions
taken with obsolete forms.

So if I understand you correctly, ODK Aggregate would return a 404 for
a form which was once good but is no longer valid. That's exactly
what I needed to know.

··· -- Vernon

On Thu, Feb 20, 2014 at 1:04 PM, Mitch Sundt mitchellsundt@gmail.com wrote:

ODK Aggregate returns a 404 -- not found.

I'm concerned you are introducing a new concept into the form processing
mechanism.

I would like formHub to match the interaction semantics of ODK Aggregate:

'form_id' designates a set of submissions that can be folded together into
one result set.

If you need to make changes that cannot be folded together, you should use a
different 'form_id'.

For a given form_id, the 'version' string is used to designate and track the
version of the form.


It is then up to you what you do with different versions of the form, and
how you determine what the threshold is beyond which you require a different
form_id be used.

Because data collectors can sync and have different versions of a form on
their devices, it doesn't seem reasonable to reject submissions from older
versions of the same form.

I am not clear whether you are trying to invalidate already-collected
submissions, or introduce re-use of a form-id for incompatible data.

Mitch

On Thu, Feb 20, 2014 at 3:59 AM, Vernon D. Cole vernondcole@gmail.com wrote:

In the interest of keeping various versions of OpenRosa compatible with
each other, I am asking for input from this group.

I am in the process of modifying formhub so that survey administrators can
switch a survey to "inactive" status at a point in time. This is considered
very important when a survey may be replaced by a newer version to insure
that data collectors do not use the newly-obsolete version. An immediate
error message when they try to submit the obsolescent data will save a lot
of trouble and misunderstanding.

I am searching for the best status code to send from the server when
rejecting the data. Clearly the 400 range is called for, an indication that
something serious is wrong with the data coming from the client. My best
guess is 406 (Not Acceptable).

The reasonable alternatives seem to be:
406 -- Not Acceptable
410 -- Gone
412 -- Precondition Failed
422 -- Unprocessable Entity

My prototype code sends error message text with the html response, but ODK
Collect (v1.4) does not display it -- only the number and description of the
status code.

Is this a good design? What changes should I consider?

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

Correct. 404

··· On Thu, Feb 20, 2014 at 12:46 PM, Vernon D. Cole wrote:

Right. I understand that the form_id must change when the form is
re-designed. This is to catch (and reject) continued use of an old
form. Yes, the survey administrators do want to invalidate submissions
taken with obsolete forms.

So if I understand you correctly, ODK Aggregate would return a 404 for
a form which was once good but is no longer valid. That's exactly
what I needed to know.

Vernon

On Thu, Feb 20, 2014 at 1:04 PM, Mitch Sundt mitchellsundt@gmail.com wrote:

ODK Aggregate returns a 404 -- not found.

I'm concerned you are introducing a new concept into the form processing
mechanism.

I would like formHub to match the interaction semantics of ODK Aggregate:

'form_id' designates a set of submissions that can be folded together
into
one result set.

If you need to make changes that cannot be folded together, you should
use a
different 'form_id'.

For a given form_id, the 'version' string is used to designate and track
the
version of the form.


It is then up to you what you do with different versions of the form, and
how you determine what the threshold is beyond which you require a
different
form_id be used.

Because data collectors can sync and have different versions of a form on
their devices, it doesn't seem reasonable to reject submissions from
older
versions of the same form.

I am not clear whether you are trying to invalidate already-collected
submissions, or introduce re-use of a form-id for incompatible data.

Mitch

On Thu, Feb 20, 2014 at 3:59 AM, Vernon D. Cole vernondcole@gmail.com wrote:

In the interest of keeping various versions of OpenRosa compatible with
each other, I am asking for input from this group.

I am in the process of modifying formhub so that survey administrators
can

switch a survey to "inactive" status at a point in time. This is
considered

very important when a survey may be replaced by a newer version to
insure

that data collectors do not use the newly-obsolete version. An
immediate

error message when they try to submit the obsolescent data will save a
lot

of trouble and misunderstanding.

I am searching for the best status code to send from the server when
rejecting the data. Clearly the 400 range is called for, an indication
that

something serious is wrong with the data coming from the client. My best
guess is 406 (Not Acceptable).

The reasonable alternatives seem to be:
406 -- Not Acceptable
410 -- Gone
412 -- Precondition Failed
422 -- Unprocessable Entity

My prototype code sends error message text with the html response, but
ODK

Collect (v1.4) does not display it -- only the number and description
of the

status code.

Is this a good design? What changes should I consider?

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

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