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.
Simple editing concepts
As the position in the visual editing environment matches the position in the XML tree it is possible to have only 2 simple concepts that an author needs to learn in order to edit any XML document. The user needs to go to the position where he want to change the document and then:
type to change the content
press "Enter" to enter markup
To help locate the current position in the document when the XML tags are not displayed oXygen provides a number of helpers
synchronized views: Outline, Model, Attributes, etc.
highlight the elements at caret position
element range marker
Alternate CSS stylesheets
The specification for associating a CSS with an XML document allows to specify multiple CSS stylesheets as alternate stylesheets - thus it is possible to switch between different renderings of the XML documents and create specific CSS stylesheets focused on different tasks that need to be performed on the XML document.
Elements can be also completely removed from the visual interface using a
: none; property on that element - thus an alternate stylesheet can provide also a
reduced view on the document.
As en example we provide for DocBook 3 CSS stylesheets
the default stylesheet
a stylesheet that hides column specifications for tables
a stylesheet that highlights the content marked with DocBook specific revision markup
The CSS support covers CSS version 1, 2 and 3.
From CSS 3 we absolutely needed support for namespaces and the
attr function to provide access to attribute values and thus be able to
provide links or to present attribute information in the visual editor. We support also the
additional attribute type parameter for the
attr function that makes this
function usable to provide dynamic values for CSS properties, values taken from the XML
attr function gives the attribute information as read only in the
content property - to be able to edit that we needed to add an
Other CSS 3 functionality supported covers transparent colors and support for custom
fonts using the
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:
no tags - no tags are visible
partial tags - inline elements are presented with small tag markers that just signal the presence of a tag
inline tags - the tags are visible for inline elements
block tags - the tags are visible for block elements
full tags - the tags are visible for all elements
full tags with attributes - both tags and attributes are visible for all elements
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 ...
condition2, etc. are XPath expressions
evaluated in the current editing context and
etc. are custom operations configured by setting values to their parameters.
Example of common operations are
ChangeAttributeOperation, "UnwrapTagsOperation" etc. and even
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