Balisage Paper: Customizing a general purpose XML editor: oXygen's authoring environment

XML and CSS

CSS is a W3C standard that can be used to provide styling information to a document. While CSS is used mainly with HTML there is no such restriction to the standard itself and it can be used also with any XML document.

The advantage of using CSS for XML editing was the fact that we were able to use the XML tree itself as the model and just compute the styles for rendering each node, there is no transformation and mapping between an output format and the XML tree. This allows to provide feedback to the user on the editing context at the caret position in the document and to combine that with the schema information to compute the DTD/schema valid markup that can be inserted at that location in the document.

Show/hide XML tag information

By default the XML tags are not visible but sometimes it is useful to have them visible in the visual editing interface. oXygen provides 6 different levels of showing markup information in the visual editing interface, from no tags at all to full tags with attributes:

Custom actions

Custom actions are part of the editing experience as they provide easy access to inserting comment fragments in XML documents. People are used with using similar actions in word processing applications and they expect similar support from XML authoring tools.

In oXygen we developed an architecture that allows defining custom actions mainly through configuration. We offer a library of common operations that should cover most of the processing needs, but user defined operations can also be added. Then, in order to define a custom action one can specify it like

     if (condition1) then operation1 
else if (condition2) then operation2 
else if (condition3) then operation3
... 

Where condition1, condition2, etc. are XPath expressions evaluated in the current editing context and operation1, operation2, etc. are custom operations configured by setting values to their parameters.

Example of common operations are InsertFragmentOperation, ChangeAttributeOperation, "UnwrapTagsOperation" etc. and even XSLTOperation and XQueryOperation - these last two allowing to use XSLT or XQuery scripts to define the logic of the action.

Form controls and inline actions

This makes possible to create a unified editing area where the user has access to all XML content, markup and attributes as well as to document specific actions added in the context they should be used from - no need for additional side views or toolbars.

The CSS styles allow the XML document to be nicely rendered and the users can easily change the content and the structure. The attribute information however it is not accessible in a similar way - it can go only into read-only labels and in order to change attributes the user needs to access them though a side panel or invoking the in-place attribute editor.

Similarly, the custom actions are generally available on the toolbar, together with all the other actions, or added to a menu or to a contextual menu.

In order to improve the editing of attribute values and to allow easier access to custom actions we added a few extension functions that can be used to bind an attribute value to a form control or to bind a button to a custom action and then put these directly in the authoring interface. These allow creating simple user interfaces that combine the visual CSS based authoring useful for mixed content editing with the simplicity of form controls and custom actions put directly in the authoring view.

Sample user interfaces

Here you can see a few sample user interfaces.

A DocBook document

All the specific support for an XML vocabulary is just a configuration and a set of resources that are packaged together is a document type or framework. oXygen provides such frameworks for many popular XML vocabularies and DocBook is one of them. You can see in the following figure the rendering of a fragment of a DocBook article.

Figure 1: The visual rendering of a DocBook document

A I-90 form fragment

Here it is a standard I-90 form fragment, implemented in XML.

Figure 2: The XML that represents the form data

Figure 3: The rendered form

A travel guide

These user interfaces, if carefully designed, allow non technical users to encode information in XML without actually knowing anything about the underlying XML format - they surely need to know the subject domain of the information they encode.

Figure 4: The XML source for a point of interest in a travel guide

Figure 5: The visual rendering of the point of interest from the travel guide