A Graphical User Interface to the "LiterateXSLT"(TM) Environment

Author: G. Ken Holman
Date: $Date: 2003/03/23 06:25:40 $(UTC)

Copyright © 2003 Crane Softwrights Ltd
http://www.CraneSoftwrights.com

Table of contents

1 Abstract
1.1 Caveat
2 Stages of processing
3 Mockup result instance creation
3.1 Importing an external-defined result instance
3.2 XSL-FO property manipulation through custom interfaces
4 Annotation of the result instance
5 Marshalling test instances through the synthesized stylesheet

1: Abstract

The "LiterateXSLT"(TM) environment is a methodology of annotating pro-forma transformation result XML instances with seeded information necessary to build the desired transformation. These annotations are elements and attributes of the LiterateXSLT vocabulary added by hand to the pro-forma transformation result.

This document describes the conceptual foundation of a graphical user interface to this annotation process. A tool implementing this interface can guide the operator in the creation of candidate result instances and the necessary annotations to synthesize the required XSLT stylesheet for a given class of source documents by using LiterateXSLT.

The GUI tool can be presented to the operator as a method of writing XSLT stylesheets when, in fact, it is but the interface to creating the input to LiterateXSLT that actually synthesizes the stylesheet code.

LiterateXSLT works with any result vocabulary. Consider that a GUI interface could have a window for the display of XSL-FO instances as formatted results from an XSL-FO engine, or the display of HTML instances as the formatted results from a browser window, or the display of XML instances as a simple instance hierarchy for use in some XML-based application.

The annotation process and the synthesis of the stylesheet are independent of any result vocabulary, thus making an opportunity for a fully-featured graphical tool for an organization needing assistance in creating the elementary versions of a stylesheet.

1.1: Caveat

Long-term use of this environment in the real-world development of stylesheets for the Universal Business Language project indicates this methodology is ideal for creating the first couple of generations of a stylesheet being authored from scratch. At some point, however, the complexity of retrofitting annotations in a literate result becomes more difficult than the typical maintenance practices needed for an XSLT stylesheet.

This methodology should not, therefore, be considered as a long-term development and maintenance strategy for production XSLT 1.0 stylesheets. Such responsibilities are best met through direct support of the XSLT 1.0 stylesheets originally produced from using this methodology.

A GUI tool built on this methodology could possibly extend the utility of LiterateXSLT beyond a few early generations, but no such a tool can be presented as "the be all and end all" of the stylesheet creation process. It would be a disservice to the user to make this tool a crutch they use to deflect their responsibility to understand the stylesheet process and syntax for long-term maintenance of their investment in XSLT.

2: Stages of processing

A GUI interface to LiterateXSLT could comprise distinct stages of processing performed in support of the operator:

3: Mockup result instance creation

The creation of the literate result instance is independent of the use of LiterateXSLT. An instance editor is very different than a stylesheet editor. An instance editor provides the immediate feedback of the instance processor, thus allowing the operator to tweak the instance for the precise presentation that is desired.


Creating and visualizing the mockup result instance
Figure 1: Creating and visualizing the mockup result instance

This "tweaking" could be presented to the user in a highly graphical drag-and-drop or pickup-and-drag user interface.

The user interface should not hide the terminology used by the result instance.

3.1: Importing an external-defined result instance

The initial version of the result tree need not be created from scratch in XSL-FO.

Consider that the user might have a desktop word processing application producing RTF or some other representation of a formatted sample result instance. Users who are migrating to XSL-FO might already have a wealth of examples from which a representative example could be drawn.

Such an instance could be algorithmically translated into an XSL-FO instance that would then be annotated with LiterateXSLT signals by the user regarding the source documents.

The translation process could be aware of LiterateXSLT features such as the triggers for using attribute sets. Such knowledge could automatically do some rudimentary LiterateXSLT annotations for style-based combinations of XSL-FO attributes from the named word processing styles.

3.2: XSL-FO property manipulation through custom interfaces

While the XSL-FO property names and values should not be hidden from the operator, the setting of these values could be assisted through highly-interactive graphical representations of the concepts being manipulated. Through either menu dialogue invocation or double-clicking on the visual representation of the formatted result, an abstraction of the formatting object could be presented, with the available components shown individually. The values could then be tweaked with the abstraction reflecting the relative changes in real-time. Through click-and-drag certain values (e.g. margin locations) could be manipulated on the fly.

Consider that a user needs to describe the page geometry and sequencing:


Page geometry and sequencing
Figure 2: Page geometry and sequencing

Consider that a user double-clicks on a list and needs to adjust properties:


List property manipulation
Figure 3: List property manipulation

Consider that a user double-clicks on a table of contents entry and needs to adjust properties:


Leader property manipulation
Figure 4: Leader property manipulation

4: Annotation of the result instance

The LiterateXSLT signals may or may not be benign to the processor presenting the annotated result instance. The striplit.xsl utility stylesheet is provided for removing LiterateXSLT vocabulary from an instance for those environments where such a contaminated instance cannot be processed successfully.

The annotation process could give graphical feedback of the range of a template rule's influence through colour-coded vertical lines in the tree.

The act of annotating could even be engaged through a drag and drop process from the source XML tree as follows:

Drag and drop annotation
Figure 5: Drag and drop annotation

It would be desirable to give the operator the chance to view the resulting stylesheet synthesized by LiterateXSLT as an opportunity to influence the annotations governing the order of the resulting template rules, as well as the tutorial and pedagogical benefits of revealing the XSLT process.

5: Marshalling test instances through the synthesized stylesheet

The GUI should also help the operator test the synthesized stylesheet. Real-world use of LiterateXSLT revealed a common problem of inadvertently forgetting a required annotation. When the synthesized stylesheet was generated and the same sample data used for the mockup was passed through the stylesheet, the results looked correct. However, running other sample data through the synthesized stylesheet revealed some of the mockup data as static content from the stylesheet and not processed from the source file.


A Graphical User Interface to the "LiterateXSLT"(TM) Environment
G. Ken Holman
Copyright © 2003 Crane Softwrights Ltd
$Date: 2003/03/23 06:25:40 $(UTC)