Integration by Parts: XSLT, XLink and SVG
If, like me, you have to repair a car, airplane (or, more modestly, the washing machine!), you'll need a parts catalog to help identify and replace some of the faulty parts.
This week's example demonstrates building an interactive illustrated parts catalog with XML technologies. The example shows how we separate the data model from the presentation, how the model is transformed into a presentation language (HTML, SVG), and finally, how scripting and CSS properties are used to implement XLink behavior and user interactivity.
Three simple steps and three XML technologies. So, let's begin with the first step.
Step 1: Encoding the Parts Catalog into XML
We won't encode an entire parts catalog in this article, just a fragment of one a single page. This page is about a small dinky toy airplane motor. The motor is the assembly of several other parts. The illustration enforces the whole-part nature of this assembly by displaying an exploded view of all the sub-parts. Each component (i.e., part) is accompanied with a visual pointer that links the component to its related information (such as its description, quantity, etc.).
In encoding the parts catalog sample, we'll use several XML technologies (such as the XLink linkage language, the SVG and HTML presentation languages, and our own custom language) to model the parts and assembly.
A part composed of other parts (such as our motor assembly)
can be perceived as a kind
of parts container. Instead of inventing a new element for
each kind of object, we simply use instead a generic
element. And, because a part can
contain other parts, a part element can contain other
We just created a recursive structure.
A part also has related information. So, let's have the
<part> element contain
other elements such as the
elements that provide, respectively, a link to a more detailed view,
a description about the part, and the quantity contained in the
assembly. Now the question is: how can we
distinguish parts that contain other parts (such as the assembly)
from the contained parts?
To model this containment relationship, we'll use the
XLink domain language. XLink is a fast-maturing W3C standard for
describing links between (and inside) documents in XML.
In particular, for our containment relationship, we will use the
xlink:extended construct, which itself is a container
A part containing other parts is a collection. Thus, in our
model, a part containing other parts will inherit from the
features and become a collection element containing locators.
A part contained in another
part inherits from the
xlink:locator features and
then becomes an element contained in a collection.
Each element contained in the collection points
to a portion of the illustration (the SVG document).
If you found that a bit hard-going, the best thing to do is to look
at the resulting XML. The parts catalog document is an XML document having as its root a
<part> element. This element
xlink:extended characteristics by
xlink:type attribute set to
"extended." The root element also contains another
xml:base, which defines the base
document location for all the contained locators.
xml:base attribute value points to
the SVG document that
encodes the small motor illustration.
<part xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="extended" xml:base="figure.svg" xlink:title="motor"> ... Locators ... </part>
Each part contained in the motor assembly is modeled as an
xlink:locator element that refers to a numbered
circle pointing to a part in the exploded view illustration (see
A contained part element (a locator) contains
a part description, a link to a more detailed view and quantity. The
<link> element points to a more detailed
external parts document if a part is composed of other parts
it is an assembly itself).
That external view is another XML document encoded the same way
as the one we are describing now.
<part xlink:type="locator" xlink:href="#part-1"> <link xlink:type="simple" xlink:href="p-102-1.svg"/> <qty>1</qty> <description>Cylinder head</description> </part>
Step 2: Encoding the Illustration into SVG
The illustration is encoded into the SVG format. A major advantage of SVG is that we can manipulate it or refer to it as an XML document. Another benefit is that we can add interactivity to its content by linking its components to script functions. Thus, SVG documents are not static images, but more interactive illustrations. These interactive possibilities will be used in our parts catalog.
To create the illustration, my girlfriend Edith first
exported an AutoCAD drawing to a DXF file. This file was then
imported in Adobe illustrator and from this she produced an SVG
document. With a small Perl program, I added additional attributes
to each visual numbered pointer, but I could just as well have
used XSLT to do so.
To make life easier, we grouped each numbered circle
with a grouping element the <g> element. Then the
Perl script added to this element some attributes like
onclick as shown below.
<g id="part-22" style="cursor:hand;fill:white" onmouseover="on_mouse_over('22')" onmouseout="on_mouse_out('22')" onclick="on_mouse_click('22')"> <path style="&st41;" d="M88.231,478.266c0-4.937-4.009-8.944-8.949-8.944c-4.94, 0-8.95,4.008-8.95,8.944c0,4.938,4.01,8.944,8.95, 8.944c4.939,0,8.949-4.007,8.949-8.944"/> <text x="72.679" y="482.308" style="&st29; &st33; fill:black;">22</text> </g>
The above SVG construct groups two visual objects. A circle encoded as a <path> element and a number contained in the circle. The number is encoded as a <text> element. The visual result is illustrated below
So, with the exception of the additional attributes, most of the content has been produced by a WYSIWYG type of program. It has to be, my girlfriend is an illustrator not a programmer. Even grouping the circle (encoded as a path element) and the number (encoded as a text element) was done with the authoring tools. In fact, in recent months, the number of authoring tools able to export SVG (and in some cases even process SVG as a native format) is increasing. Here is a shortlist:
- Adobe Illustrator 8.01 With the SVG plug-in
- Corel 9 with the Corel SVG plug-in
- Jasc Trajectory Pro
- Mayura draw
As you can see from the SVG source,
the authoring tool made intensive use of the
<path> element. This is a trend that I also
noticed with several other authoring tools.
So, the illustration is encoded in a separate SVG document, and the parts catalog sample model is encoded in another XML document. To be rendered in a browser, the parts catalog document needs now to be transformed into a presentation language HTML (or XHTML).
Step 3: Transforming the XML Model into a Displayable Document
Our presentation strategy involves two languages: CSS, for the run-time dynamic modification of visual objects' properties; and XSLT, to transform the XML document into HTML.
The XSLT sheet creates an HTML document that embeds the SVG document at the top. It then adds an HTML table underneath the illustration. The table contains, for each part, related information such as the part number, description, and quantity. When the mouse cursor is over one of the illustration's visual pointers, this circled number is colored in yellow, and its related information located in the HTML table is also colored in yellow. When the user clicks on a visual pointer, it is then colored in gray and so is its related information in the table. Both visual entities stay grayed until the user clicks again on either the table row or on the illustration visual pointer. This last feature allows the user to select a particular part, then scroll the document to read the part's highlighted information.
The style sheet template associated with the XML document
match="/") produces the core HTML constructs
and the script section. The script section contains functions that
will react at run time to events such as when the mouse
cursor is over a visual pointer, when the mouse cursor is leaving
the visual pointer, and when a mouse button is pressed.
When the mouse cursor is over a visual pointer, the style
properties (specifically, the fill attribute's value) of the
<g> element change from white to yellow.
Thus, the script dynamically changes an
SVG element's property.
This dynamic behavior is a benefit of SVG
using CSS properties for its visual objects.
The script also changes
the corresponding HTML row element's style.
Thus, both the SVG and HTML elements' visual appearance are
dynamically changed through CSS properties.
<part> elements are differentiated by the
xlink:type attribute. If the
is set to "extended," then the template embeds the SVG document
into the rendered document. The embedded document's location is
specified by the
The template also creates an HTML table that
will include all the other contained parts, which are also
xlink:locator elements that point to other elements
contained in the SVG document.
To render the SVG document, the
freely available Adobe SVG viewer is used as a browser plug-in. This is the plug-in that is embedded in the rendered HTML document. Finally, each
<part> element with an
xlink:type attribute set to "locator" is transformed
into a table row. Thus, the final rendered HTML document includes an
embedded SVG document and a table.
The Resulting HTML Document (requires SVG plug-in to view)
Unfortunately, current reality is that browsers do not support X-Linking to elements contained in different documents. And in fact, with the exception of Mozilla (Milestone 14) and Hybrick, none support XLink constructs at all. To compensate for this weakness, scripting could be used to link elements together, to provide XLink interpretation and, more particularly, the kind of XLink behavior that you require. As you can see by viewing the result of the XSLT transformation, the elements contained in the HTML table are linked to the elements in the SVG document and vice versa.
The parts catalog document can be rendered in a browser IE5 with MSXML3.DLL installed. This will properly render the XML document by transforming it to HTML. Notice here that we used XSLT constructs that are compliant to the W3C Recommendation. You can also process the XSLT style sheet without any modifications either with XT or SAXON. (I didn't test it with Xalan or the Oracle XSLT engine but I expect that the style sheet will work with these engines too.)
For more sophisticated presentation, it seems that the combination of CSS, scripting, and XSLT is required. By modifying the CSS properties dynamically at run time, we can provide a particular XLink interpretation and behavior. If a future XSLT Recommendation includes a standard way to output multiple documents from a single style sheet, then the XLink interpretation could be provided by the XSLT style sheet.
I encourage you to play with the part catalog sample by downloading the zipped package that includes the documents I used for this experiment. A big thank you to Edith Duval who helped me create the SVG document.