Balisage Paper: Generating Schema-Aware XML Editors in XForms

Displaying structures, editing data values

We first present simplified editors that allow editing of purely textual element content, but just display the document structure, not yet enabling structural editing. These editors could be used as classical form editors for a structurally-fixed XML-encoded form. At first, we restrict ourselves to elements. This is not a severe restriction; it will be easy to add attributes and editing support for them. Furthermore, we do not allow mixed content yet. Finally, we exclude recursive type definitions for now; this feature of XML Schema requires further techniques, that fall outside the scope of this section.

The challenge of this section is to generate a static structure of XForms widgets that only depends on the input schema but that is able to bind to any XML instance, that conforms to the schema, and to display it. The key idea is to generate a liberal structure of XForms widgets that is capable of displaying a superset of the required XML instances. For example, if the schema uses a choice operator, we generate widgets for all alternatives. Each widget tries to bind to some element in the XML instance, but only some of them succeed, depending on the choice that the current instance realizes. We rely on the fact that "superfluous" widgets do not display when the referenced nodes in the current XML instance do not exist. We call this principle Liberal Inputs.

Let us look at the schema liberalInputsS, see Figure 2. It provides one root element, xyz, that can have one or two subsequences of one or two subelements a and one or two subelements b. Element a is typed as xsd:int and element b is typed as xsd:boolean. Now we are looking at the editor that we have generated, the XForms document liberalInputsF, see Figure 3: It has a repeating group of one widget refering to an element a and one widget refering to an element b, each of which enables editing of the element's text content. Finally, let us load the editor with the XML instance liberalInputsI in Figure 4 that conforms to the schema liberalInputsS. Then, the XForms element xforms:repeat iterates over all children of element xyz in the current XML instance, displaying the appropriate input widget for each element a or b that is met, as illustrated in Figure 5. This form could in principle display any sequence of elements a and b, even those that do not conform to the type of element xyz, depending on the XML instance. But we may assume that the XML instance is valid with respect to the schema when it is loaded; and the user interactions that we will later introduce, always preserve validity. Hence, it does not matter that the widget structure is more liberal than the schema.

Figure 2: XML Schema liberalInputsS

Figure 3: XForms liberalInputsF

Figure 4: XML instance liberalInputsI

Figure 5: Editor screen shot liberalInputsB

Some further points and easy generalizations:

We can now algorithmically describe how to generate an XForms editor that allows editing of text content but only displays structure [Maa13].

Editing structures: The downwards-facing perspective

One novelty of this work is that our editors support editing not only of data values, as demonstrated in the previous section, but also of structures. XForms provides some basic support for insertion and deletion of nodes in an XML instance, with its actions xforms:insert and xforms:delete that can be triggered under user control. The challenge is to make sure that editors only allow for schema-conformant changes of XML instances.

In this section, we take the downwards-facing perspective. We demonstrate our Prototype principle, which guarantees that only such element structures are inserted into an XML instance that by themselves conform to their declared type. We'll address the upward-facing perspective, how deletions and insertions of children nodes can be forced to respect their parent's type, in the next section.

If we wish to insert an element that conforms to some type into an XML instance, we'll insert a whole structure, with subelements and attributes as required by the type. We precompute in XFGen one minimal structure that conforms to the type and call it the element's prototype [Maa13].

The xforms:insert action cannot create new structures; rather, it can only clone structures that are already present somewhere in the form's model. Therefore, XFGen builds an auxiliary instance that holds all prototype element structures and attributes of the schema, which can then be cloned and inserted into the form's XML instance under action control.

Once a prototype has been inserted into the XML instance, the user can further edit it. Right now, XFGen computes some arbitrary prototype that conforms to the required type definition and cannot be further reduced by omitting attributes or subelements. The schema author can influence which prototype is generated by the order of choice operands in a type definition. Currently, XFGen always instantiates the first choice operand for a prototype.

The auxilliary instance with the prototypes for Schema liberalInputsS in Figure 2 is in Figure 6.

Figure 6: Auxilliary instance liberalInputsP

Editing structures: The upward-facing perspective

We now address the problem how to support insertion and deletion of children nodes such that the result necessarily conforms to the parent node's type.

Let us consider schema editControlsS in Figure 7, that allows top-level element xyz to have subelements a, b and c with the following additional constraints: The subelements of xyz either form a nonempty sequence of a, followed by a nonempty sequence of b, or consist just of a single c. In compact regular-expression notation, that is (a⁺b⁺)|c.

Figure 7: Schema editControlsS

Our goal is to offer a finite number of primitive edit operations, so that any schema-conformant sequence u₁...u_m of children of xyz can be transformed into any other schema-conformant sequence v₁...v_n by applying a finite number of the primitive edit operations, one after another, in such a way that each intermediate step leads also to a schema-conformant intermediate sequence.

In our example, we generate the following set of primitive edit operations:

For simplicity's sake, we include "P7: insert c" in our supply of primitive edit operations, although it can never be used in a schema-conformant transformation. We can only insert a c if we also delete every a and b that might be present. And we can break down such a combined operation into a number of primitive edits, first deleting any single a and b except one, respectively, with P3 and P4, and then deleting the last remaining sequence ab and simultaneously inserting c with P5. Following the same argument, P8, P9 and P10 can also never be used in a schema-conformant transformation.

We cannot do without primitive P5 simulating P5 by the sequence P3 P4 P7, since intermediate states would not be schema-conformant.

Of course, unwise application of primitive edit operations can lead to non-schema-conformant states. If we apply P5 in the middle of sequence aab, between a and b, we erroneously get the invalid sequence ac.

Our claim is the following: For any complex type definition, we can compute a finite number of primitive edit operations such that we can transform any conformant sequence into any other conformant sequence using the primitive edit operations and having only conformant intermediate states. We stress once more that this is an "existential" claim. We do not care at this point, that our primitive edit operations can also generate non-conformant sequences when applied at wrong positions. Maalej [Maa13] has the algorithm to generate a sufficiently large but finite set of primitive edit operations. Further research is needed to investigate if one can compute a minimal such set or if a minimal set would be unique.

Following a principle that we call Liberal Edits, we include any of the primitive edit operations as one button in the editor's user interface at any position in the sequence of children of xyz, see editControlsUI.xml.

We can do this generically, without refering to a specific instance, by utilizing xforms:repeat, as previously. Note that we insert one set of buttons outside the xforms:repeat to handle the beginning of the sequence.

Finally, we still need to control which of the edit buttons that we have so liberally included in our editor are actually active and which are passive (not shown), to preclude illegal edits that lead to non-conformant documents.

In our example, we could do this with XPath bindings into the instance. We can, for example, express that P3 is only active if there is another a among the children of xyz, apart from the one that is to be deleted.

However, an educated guess leads us to believe that, in the general case, the expressive power of XPath is too weak compared to the power of regular expressions in XML Schema complex types. Hence, we offer a different approach that we call Try and Tell.

We bind to each edit button a script that experimentally performs the primitive edit operation on a copy of the current instance, validates the result and makes the button visible only if the result is in fact valid. These scripts are triggered by XForms refresh events that are activated after each user interaction, ensuring up-to-date visibility status of each edit button. The scripts are implemented in a scripting language for which the XForms processor provides an interface, in our case in XBL (see also the section on implementation below.

We illustrate the effect of Try and Tell for schema editControls in Figure 7 with a browser screenshot in Figure 8.

Figure 8: Editor screen shot editControlsB

Editing mixed content

In XML Schema, elements that are typed to have element content can orthogonally be declared to be of mixed content, allowing text-node children to be interspersed at any position in an element's instantiation, at the beginning, the end and between element nodes. This is in contrast to the more powerful Relax NG, where the appearance of text nodes can be constrained by regular-expression rules in the same way as subelements. The orthogonal approach of XML Schema opens up the opportunity to decouple handling of text nodes in mixed content from the handling of structured content, in a simpler and platform-independent way.

In a first attempt, we apply our principle Liberal Inputs to elements that are declared to be of mixed content, iterating in the form's user interface not only over the elements' child elements but also the child text nodes, generating input widgets in the user interface for display and editing of these text nodes. This will display and make editable any text nodes that are present in the current document instance but does not handle positions in the document instance where text nodes are allowed but do currently not exist. For this case, we introduce a new principle, Automatic Text Insertion. When the document instance is loaded into the form, we automatically trigger a script (written in JavaScript) that inserts dummy empty text nodes at any position where a text node is allowed by the schema but none is present in the instance. Then, input widgets appear at any position in the user interface, where text nodes are allowed by the schema, displaying an empty input field for the dummy text nodes and the original text for text nodes that were already present in the document instance. These text nodes can be edited via the input widgets; they can also be "deleted" by resetting their content to the empty string.

Unfortunately, there is a glitch with this approch: The iteration in the form's user interface will also produce the set of buttons for primitive edit operations that would consequently also have to be managed. There is, however, a slightly different way to deal with text nodes without considering buttons for primitive edit operations: We couple the widgets for text nodes to the groups for element nodes within an xforms:repeat and insert a further widget for a text node outside the xforms:repeat, to handle the text node that appears before the first element. We call this principle Coupled Inputs and demonstrate its application with schema coupledInputsS in Figure 9, XForms coupledInputsF in Figure 10 and browser screen shot coupledInputsB in Figure 11.

Figure 9: Schema coupledInputsS

Figure 10: XForms coupledInputsF

Figure 11: Editor screen shot CoupledInputsB

The last point to consider is how structural edit operations deal with text nodes. Here we modify the edit operation in such a way that empty text nodes are inserted as needed and that the contents of text nodes that are deleted together with a sequence of neighboring element nodes are copied into the remaining text node in front of them.

This solution for mixed content is essentially platform independent. It uses a custom JavaScript script that is triggered by a built-in XForms event and accesses the document instance through the standard DOM interface. Furthermore, it utilizes the capability of XForms to associate the script with the event. It is worth mentioning, though, that XForms makes it really hard to insert text nodes in the middle of a sequence of nodes, demanding to sequentially build up of the sequence from front to back.