Declarative schemea-directed data model management

A form is received and loaded. It is determined if a schema structure definition defines one or more choice elements for data of the form. A data structure is created for the data, the data structure includes both a schema structure valid component and a non-validated component. When a user selects one of the choice elements, a first set of zero or more data elements corresponding to the selected choice element are loaded into the schema structure valid component of the data structure. The previous set of zero or more data elements and values associated with the previous set of data elements are then stored in the non-validated component of the data structure.

BACKGROUND

This invention relates generally to processing within a computing environment, and more particularly to declarative schema-directed data model management.

Web applications typically use forms to collect data and store that data in a database. Extensible markup language (XML) is often used to store and transmit data to and from web applications. Through the use of an XML schema, data within an XML document may be validated. Web applications that collect XML data can be designed to be conformant to an XML schema. The XML Schema often has optional subtree elements or a choice of alternative subtree elements.

One example is that of a payment detail component of a transaction data definition. A “payment” element may include a first sub-element for a “payment type” such as collect on delivery (COD), credit card, bank direct payment card, etc. These payment detail element choices would allow storage of a customer ID for COD or card number, expiry and other info for credit card, etc. According to the XML schema, the payment element of the XML document is not considered valid if payment detail elements corresponding to both the COD and credit card options appeared within it.

Managing these choice and optional nodes creates a compromise between server side manipulation of data, and the removal of data leading to an inconsistent user experience on the client side. Both approaches lead to additional development work, additional maintenance and/or negative customer experience impact.

BRIEF SUMMARY

An additional embodiment includes a system for declarative schema-directed data model management. The system includes a processor configured to execute a declarative schema-directed data model management module, the declarative schema-directed data model management module configured to received and load a form. It is determined if a schema structure definition defines one or more choice elements for data of the form. A data structure is created for the data, the data structure includes both a schema structure valid component and a non-validated component. When a user selects one of the choice elements, a first set of zero or more data elements corresponding to the selected choice element are loaded into the schema structure valid component of the data structure. The previous set of zero or more data elements and values associated with the previous set of data elements are then stored in the non-validated component of the data structure.

An embodiment includes a computer program product for declarative schema-directed data model management. The computer program product includes a tangible storage medium readable by a processing circuit and storing instructions for execution by the processing circuit for performing a method comprising receiving and loading a form. It is determined if a schema structure definition defines one or more choice elements for data of the form. A data structure is created for the data, the data structure includes both a schema structure valid component and a non-validated component. When a user selects one of the choice elements, a first set of zero or more data elements corresponding to the selected choice element are loaded into the schema structure valid component of the data structure. The previous set of zero or more data elements and values associated with the previous set of data elements are then stored in the non-validated component of the data structure.

DETAILED DESCRIPTION

An embodiment of the present invention provides for declarative schema-directed data model management. In an embodiment, the live XML document representing the web application form data is maintained as a valid XML document per the schema. The XML schema document is scanned to determine if there are any choice data elements (i.e., data elements where a user must select one and only one option from a list of options.) The choice data elements create varying data requirements depending on which choice the user selects. If any choice elements are found in the XML schema, all of the various trees are created for each permutation of valid options. As a user makes a selection, the choice node of the XML tree related to that choice is pruned, and the XML tree related to the selected choice is placed in the XML document in its place. The pruned tree is then stored with all of its values intact. If the user reselects the pruned version, the current XML tree related to the choice is pruned, and the old XML tree is replaced including the data that the user previously selected. The user experience is therefore enhanced, while the XML document's data integrity and validity is maintained.

In an embodiment, when the form is submitted, only the XML tree related to the last selected choice is stored in the database. When a user retrieves the form once more, the data is extracted from the database, and the other XML tree choice options are created and hidden from the user. The user is then allowed to change choice options without issue.

In current practice, an XML document must be created that contains all possible choices of payment details in order to enable user interface controls to easily bind to them and provide values. Then, XML relevant rules are used on each of the payment detail child elements to help indicate which payment detail elements are relevant and which are non-relevant based on the payment type selected by the user. The resulting form is functional, but there are two problems. The data instance within the form is not schema valid, therefore validating the whole form document using the data schema for those elements in the data schema's namespace is not possible because the extra elements in the XML document violate the XML schema. In addition, if the whole document is submitted to the server, extracting the data instance within it produces XML data that is not schema valid. The server side must therefore be able to prune the non-relevant nodes, which imposes a significant processing burden on the server side.

An additional way to handle choices and optional fields in a web application is, stripping the non-relevant payment detail elements automatically from the data before it is submitted. This provides a schema valid data instance to the server, but that data instance can never again be used in the same form to drive further client-side interactivity in a later interaction session because the non-relevant payment detail child elements have been physically removed. Relevance pruning is supposed to be the last act of a completed transaction. But once a subtree is physically removed, it cannot become relevant later, if for example a user wishes to change the payment type, they cannot because a subtree must exist in the data in order to change from non-relevant to relevant.

As an alternative, it would be possible to use several features of a language such as XForms language to construct a template-based solution. By, for example, creating instance data templates for optional and choice element subtrees, and then when a user makes a data setting that changes an optional element from shouldn't exist to one that should exist, inserting the element from the template into the document. When the user makes a data setting that changes an optional element from what should exist to one that shouldn't exist, the element is deleted from live instance data. Another option is when the user makes a data setting that changes a choice from one subelement to another, then the unwanted subelement is deleted and the desired subelement is inserted in its place.

There are two problems with this approach. First, it is based on manually constructing an event-drive imperative solution, which is analogous to the existing solution to the problem prior to the XML implementation. In addition, this latter solution is template-based. Therefore, if a user makes choice 1 corresponding to subtree A, then fills in part of subtree A, then changes their mind to choice 2 corresponding to subtree B, then subtree A is delete and the data filled into it is lost. This is a usability problem in the human interaction domain if the user decides choice 2 was a mistake and tries to return to choice 1. Subtree A comes back, but it is the empty template A.

Turning now toFIG. 1, a system100for implementing declarative schema-directed data model management will now be described. In an embodiment, the system100includes a host system computer102executing computer instructions for declarative schema-directed data model management. Host system computer102may operate in any type of environment that is capable of executing a software application. Host system computer102may comprise a high-speed computer processing device, such as a mainframe computer, to manage the volume of operations governed by an entity for which the declarative schema-directed data model management is executing. In an embodiment, the host system computer102is part of an enterprise (e.g., a commercial business) that implements the declarative schema-directed data model management.

In an embodiment, the system100depicted inFIG. 1includes one or more client systems104through which users at one or more geographic locations may contact the host system computer102. The client systems104are coupled to the host system computer102via one or more networks106. Each client system104may be implemented using a general-purpose computer executing a computer program for carrying out the processes described herein. The client systems104may be personal computers (e.g., a lap top, a personal digital assistant, a mobile device) or host attached terminals. If the client systems104are personal computers, the processing described herein may be shared by a client system104and the host system computer102(e.g., by providing an applet to the client system104). Client systems104may be operated by authorized users (e.g., programmers) of the declarative schema-directed data model management described herein.

The networks106may be any type of known network including, but not limited to, a wide area network (WAN), a local area network (LAN), a global network (e.g., Internet), a virtual private network (VPN), and an intranet. The networks106may be implemented using a wireless network or any kind of physical network implementation known in the art. A client system104may be coupled to the host system computer102through multiple networks (e.g., intranet and Internet) so that not all client systems104are coupled to the host system computer102through the same network. One or more of the client systems104and the host system computer102may be connected to the networks106in a wireless fashion. In one embodiment, the networks106include an intranet and one or more client systems104executing a user interface application (e.g., a web browser) to contact the host system computer102through the networks106. In another embodiment, the client system104is connected directly (i.e., not through the networks106) to the host system computer102and the host system computer102contains memory for storing data in support of declarative schema-directed data model management. Alternatively, a separate storage device (e.g., storage device112) may be implemented for this purpose.

In an embodiment, the storage device112includes a data repository with data relating to declarative schema-directed data model management by the system100, as well as other data/information desired by the entity representing the host system computer102ofFIG. 1. The storage device112is logically addressable as a consolidated data source across a distributed environment that includes networks106. Information stored in the storage device112may be retrieved and manipulated via the host system computer102and/or the client systems104. In an embodiment, the storage device112includes one or more databases containing, e.g., declarative schema-directed data model management data, code and corresponding configuration parameters, values, methods, and properties, as well as other related information as will be discussed more fully below. It will be understood by those of ordinary skill in the art that the storage device112may also comprise other structures, such as an XML file on the file system or distributed over a network (e.g., one of networks106), or from a data stream from another server located on a network106. In addition, all or a portion of the storage device112may alternatively be located on a client system104.

The host system computer102depicted in the system ofFIG. 1may be implemented using one or more servers operating in response to a computer program stored in a storage medium accessible by the server. The host system computer102may operate as a network server (e.g., a web server) to communicate with the client systems104. The host system computer102handles sending and receiving information to and from the client systems104and can perform associated tasks. The host system computer102may also include a firewall to prevent unauthorized access to the host system computer102and enforce any limitations on authorized access. For instance, an administrator may have access to the entire system and have authority to modify portions of the system. A firewall may be implemented using conventional hardware and/or software as is known in the art.

The host system computer102may also operate as an application server. The host system computer102executes one or more computer programs to provide the declarative schema-directed data model management. The host system computer102includes a declarative schema-directed data model management module108. As indicated above, processing may be shared by the client systems104and the host system computer102by providing an application (e.g., java applet) to the client systems104. Alternatively, the client system104can include a stand-alone software application for performing a portion or all of the processing described herein. As previously described, it is understood that separate servers may be utilized to implement the network server functions and the application server functions. Alternatively, the network server, the firewall, and the application server may be implemented by a single server executing computer programs to perform the requisite functions.

It will be understood that the declarative schema-directed data model management described inFIG. 1may be implemented in hardware, software executing on a general purpose computer, or a combination thereof.

FIG. 2is a schematic diagram of a data and user interface abstraction in an embodiment. In an embodiment the components that make up the data and user interface abstraction ofFIG. 2are executed in the system ofFIG. 1. The user interface layer202includes logic for display text, forms and form data on, for example, a web browser. The user interface layer202provides controls for making selections, such as form selections via controls (i.e., a radio button, dropdown, etc.) and for submitting the forms. In an embodiment, as data is modified at the user interface layer202, the changes to the data are sent to a data processing layer204. The data processing layer204processes the changes to the data, including the manipulation of the data elements when a choice is selected in the user interface layer202as will be described in more detail below. The data is validated against validation rules (i.e., an XML schema) at a data validation layer206. In an embodiment, the data validation layer206validates the correctness of the data elements, and/or tests the validity of the data container (i.e., an XML document). Valid data is then saved to a data storage layer208(such as a database).

FIG. 3depicts a process flow that may implemented by a declarative schema-directed data model management module for initializing a form in an embodiment. In an embodiment, the process flow ofFIG. 3is performed by the declarative schema-directed data model management module108ofFIG. 1. At block302, a form is loaded. In an embodiment, the form is a web form that is loaded in a browser. At block304, the XML schema structure definition is reviewed and it is determined if the XML schema contains any choice fields.

Choice fields represent multiple options in a form, wherein each of the options corresponds with a particular set of data fields. Only a single option may be selected at a time, and the form's main data structure must only contain the data fields associated with the selected option in order to be considered valid. As a result, as a user of a form chooses an option, the underlying data structure is changed to accommodate the fields associated with the selected option. The main data structure is created based on a schema document that corresponds with the form that has been loaded, and is created to include only the selected options of the choice fields. In an embodiment, the unselected options are stored as orphan data objects, with all of their data and attributes maintained. In an embodiment, the form's main data structure is an XML document, and the schema document is at least one XML schema document.

If there are no choice fields in the XML schema, then processing ends at block308. If there are choice fields in the XML schema, then processing continues at block306. At block306, a composite data structure is created to contain the data for the form. In an embodiment, the data structure includes a main data structure component that is schema structure valid (i.e. it conforms to the schema structure definition) and a second non-validated component for housing the orphaned data objects corresponding to all of unselected options of all the choice fields defined in the schema. Once the choice data structures have been created the form load is complete and processing ends at block308.

FIG. 4depicts a process flow that may implemented by a declarative schema-directed data model management module for processing user input in an embodiment. In an embodiment, the process flow ofFIG. 4is performed by the declarative schema-directed data model management module108ofFIG. 1. At block402, a user initiates input into the loaded formed, such as the form loaded atFIG. 3. At block404, it is determined if an option in the form is selected by the user. If a user has selected an option, then processing continues at block406.

At block406, the current data structure for a choice is orphaned (i.e., pruned from the main data structure) and is stored in the non-validated component of the composite data structure. In an embodiment, the orphaned components are only stored in the non-validated component in an optimized fashion, i.e. only when the user is presented with portion of the user interface that allows them to make a choice. In an embodiment, with large multipage forms, only some of the form user interface is presented at any one time. Therefore only when presenting a particular page are the non-validated components, and the orphaned components created.

At block408, the orphan data object associated with the selected choice is retrieved from the location where it has been stored, and is added to the main data structure, i.e. in the schema structure valid component, where the previous choice data structure was removed.

At block410, it is determined if the user has requested that the data entry session be ended. If the user selects to end the session, processing continues at block412. At block412, the schema structure valid component including non-orphaned data is saved in some application-specific way. In and embodiment, the schema structure valid component may be transmitted over the network106and stored in the database (i.e. placed in the storage device112.) Alternately, the schema structure valid component may be indirectly saved by storing it in the original form and transmitting the updated form for storage in a document management repository. Alternately, the schema structure valid component may alternately be saved in a more sophisticated manner, such as in the working memory of web application code equipped to extract data values from the schema structure valid component for subsequent use in business process steps, business transactions or database operations. At block414, processing ends. Returning to block410, if the user has not requested to end the session, then processing continues at block416, where the user's interaction with the form is processed normally. Processing then continues at block404. Returning to block404, if it is determined that a user did not select an option, then processing continues at block416, where the user's interaction with the form is processed normally. Processing then continues at block404.

FIG. 5depicts a process flow for reloading a form once a session has been saved in an embodiment. In an embodiment, the process flow ofFIG. 5is performed by the declarative schema-directed data model management module108ofFIG. 1. At block500, a request is received to restart a data entry session. In an embodiment, data entry is performed in sessions, and as stated above when a session is completed the orphaned elements are pruned from the data structure and the selected data are stored. A user may restart a data entry session in order to make changes to the selected data. At block502, the form is loaded at the browser. At block504, data is retrieved from the database, such as a database in the storage device112ofFIG. 1. At block506, the XML schema associated with the form is reviewed and it is determined if the XML schema contains any choice fields. If the XML schema has no choice fields, then processing ends at block516.

Otherwise, if the XML schema does have choice fields, then processing continues at block508. At block508, it is determined, based on the data, which choice was previously selected. In an embodiment, the data contains a specific indicator of which choice was selected. At block510, orphaned data elements are created for any of the choices that were not the selected choice. At block512, the data elements are loaded onto the form. At block514, the choice that was previously selected is preselected on the form. At block516, processing ends.

Although the embodiments describe the use of XML schemas, it will be understood that in other embodiments the various flows and systems may be used in conjunction with any other validation scheme (i.e. rules, business objects, etc.) that support the use of optional and/or multi-choice form values.

Technical effects and benefits include the ability to retain and repopulate multi-choice data in a form, as a user of the form changes selections, while maintaining a valid intermediate data structure. An additional benefit is the ability to recreate the various options in a form once the session has ended, and the orphaned data elements are pruned from the document.

As described above, embodiments can be embodied in the form of computer-implemented processes and apparatuses for practicing those processes. In embodiments, the invention is embodied in computer program code executed by one or more network elements. Embodiments include a computer program product on a computer usable medium with computer program code logic containing instructions embodied in tangible media as an article of manufacture. Exemplary articles of manufacture for computer usable medium may include floppy diskettes, CD-ROMs, hard drives, universal serial bus (USB) flash drives, or any other computer-readable storage medium, wherein, when the computer program code logic is loaded into and executed by a computer, the computer becomes an apparatus for practicing the invention. Embodiments include computer program code logic, for example, whether stored in a storage medium, loaded into and/or executed by a computer, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the computer program code logic is loaded into and executed by a computer, the computer becomes an apparatus for practicing the invention. When implemented on a general-purpose microprocessor, the computer program code logic segments configure the microprocessor to create specific logic circuits.