ODK Collect and ODK Aggregate follow the OpenRosa standards
Aggregate requires the version attribute, if used, be a number. We
recommend "2012071901" (e.g., yyyymmddnn -- nn is a counter for each new
version on that day) as the version number, so that newer versions can be
distinguished from older ones.
Aggregate looks for the OpenRosa version header (
https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaRequest ), and if
present, replies with the OpenRosa response format.
*If this header is absent, Aggregate replies with the Aggregate 0.9.x
···* ODK Collect will contact aggregate at /formList as the server path for the FormDiscovery API, but opening a browser to http://opendatakit.appspot.com/formList shows the older 0.9.x response because your browser doesn't supply the OpenRosa version header on its request, causing the above fallback behavior to take effect. You can see the OpenRosa-style form discovery response that is actually returned to ODK Collect by browsing to http://opendatakit.appspot.com/xformsList e.g, add /xformsList to the end of your server URL -- this special /xformsList path forces the response to show as an OpenRosa response, but is only for debugging purposes.
On Fri, Jul 20, 2012 at 6:22 AM, email@example.com wrote:
We're developing an application that will send forms to and receive
submissions from ODK Collect. Is there a specification to the ODK Aggregate
protocol that we can consult while implementing?
University of Washington