Browse Prior Art Database

Processing and Surfacing Versioning Information During Form Generation Disclosure Number: IPCOM000132062D
Original Publication Date: 2005-Nov-30
Included in the Prior Art Database: 2005-Nov-30
Document File: 3 page(s) / 48K

Publishing Venue



When the nature of data that needs to be collected from an end-user changes, any existing forms that serve as collection instruments must also change. Not only must the new form be able to be generated automatically and quickly, the specifics any changes between versions of a form likely will have to be known made to the user, so that the user may make appropriate adjustments to previously-entered data, or to remind the user that a change has occurred since the last time they filled out a version of the current form.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 3

Processing and Surfacing Versioning Information During Form Generation

As an example of form data that would need to be highlighted as versions change, assume that version 1.0 of a form has an entry field named "favorite color". In version
1.0, the options are "red" and "green". A user fills out version 1.0 of the form, selecting his favorite color, "green", from among those options.

However, when version 2.0 of the form is released, "yellow" has been added as an option. The next time a user attempts to update the data previously submitted with version 1.0 of the form, he will do so through an instance of version 2.0. Futhermore, although his previous selection of "green" is still valid, the new option, "yellow", actually is his favorite color. However, since "yellow" was not available in version 1.0 of the form, the user selected "green" as her second-best choice.

The user should somehow be informed, upon opening version 2.0 of the form, that the "favorite color" field has changed. The form author may even wish to ensure that a user explicitly acknowledges that he has seen and understood the nature of the change before being able to re-submit the form data.

Similar scenarios would occur if other properties of a data node were changed, or if a data node were removed, or added between versions.

This is a trivial example of a scenario that is very real and carries some urgency. Imagine that there is an outbreak of some new disease, or some disaster for which planning has not been sufficient. The data that may be submitted from field agents on the scene could vary from day to day or even from hour to hour as more is understood about the situation, and the need to collect new data is discovered, or it is found that clarifications are needed in the way the form requests data.

Providing a way for a user to acknowledge changes before submission of data from a new version of the form also is quite important to provide traceability when official/legal accountability is required. Whether or not a change was read and acknowledged by a submitter might help enforce any argument that the submitter is or is not at fault in a given case that arose from data apparently submitted from that form. Optionally requiring acknowledgement of specific changes also could ensure accountability across form versions.

These contingencies require a method for providing for the processing and surfacing of versioning information at the data-node level, during automated generation of a form. The current alternative to using our technique would be to manually insert form markup to handle version-change situations, which would be brittle and time-consuming.

A methodology whereby version differ...