[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: XSLT and SVG

Subject: RE: XSLT and SVG
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Tue, 18 Jul 2006 15:49:56 -0400
graphviz xslt
Andrea,

As someone who's also played around quite a bit with XSLT/SVG, I'd amplify and qualify what Charles says.

The hard part isn't the SVG rendering. As you are finding, it's in deriving the parameters you need for said rendering, which are used at various points in your SVG, including at the top (scaling the entire image) and throughout (placing the boxes and connectors relative to one another). In simple cases this is doable in XSLT by itself, but the complexity of the problem goes up very rapidly the "deeper" (more implicit) in your data are the factors that determine the specifics (as in: x,y) of the layout.

Thus, due to the fact that in the scenario you describe, the information needed to map locations is only implicit in the relationships between nodes in an XML source document, it's not an easy transformation. That's the gap that graphviz helps you to cross, since it's written precisely to handle the calculations necessary.

Since graphviz outputs SVG and SVG is XML, it should be possible to tweak or repaint graphviz output using XSLT, if necessary.

If you wanted to try doing this by hand, I'd recommend you:

* Use XSLT 2.0 since pipelining will be useful if not absolutely necessary (this is considerably more cumbersome in XSLT 1.0), to say nothing of features like user-defined functions, or of XPath 2.0, with handy functions like min() and max(); and

* Study up on your graph theory and the processing algorithms that have been developed for graph rendering.

Note this would *not* be a beginner-level transformation. Also, SVG (which in version 1.0 lacks certain desiderata such as constraint-driven formatting, e.g. "draw a box big enough to hold this label") may be a bit underpowered for some requirements you might have, so you should be cautious going in.

Cheers,
Wendell

At 02:32 PM 7/18/2006, you wrote:
You will save a lot of time if you use graphviz (http://www.graphviz.org/) to produce your SVG. Use XSLT to transform your XML to the graphviz "dot" language and then process the output with graphviz to yield SVG. Connecting nodes is a trivial effort and the dot language is very simple.
--
Charles Knell
cknell@xxxxxxxxxx - email


-----Original Message-----
From:     Andrea Pertosa <andrea.pertosa@xxxxxxxxx>
Sent:     Tue, 18 Jul 2006 13:08:28 -0400
To:       xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject:   XSLT and SVG

HI all and thanks for reading!!

First I have to confess that I'm a beginner, so please be forgiving!!

I started looking at XML/XSLT some time ago, and I have to admit that
the learning curve is a bit too steep for me.

The scenario: my XML file contains bodies and joints and represents a
mechanical system.

The idea: instead of looking at the XML text in order to figure out if
the mechanism is well-formed, wouldn't it be cool to develop an XSLT
that transforms the XML file so that the mechanical system is
presented in a graphical way?

The (I think) solution: define an XSLT that creates a block diagram
made of rectangles (or circles...) for each body and a connecting line
between the two rectangles that a joint connects.

Sounds easy, no?

   Unfortunately I'm running into problems and I thought that if I
published what I have done so far, perhaps someone could tell me if
I'm on the right track or not, since I'm sure there   are many
examples of XSLT that create graphical representation of hierarchical
structure. Think of an org chart...

--------- the XML file ------------

<MultiBodySystem>
 <Model>
  <Body_Rigid
     label               = "Ground"
     id                  = "30101"
  />
  <Body_Rigid
     label               = "Body 1"
     id                  = "30301"
  />
  <Body_Rigid
     label               = "Body 2"
     id                  = "30302"
  />
  <Constraint_Joint
     body1_id            = "30101"
     body2_id            = "30301"
  />
 </Model>
</MultiBodySystem>

------------ the xslt file ---------------

<?xml version='1.0' encoding='utf-8' ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" indent="yes" version="1.0" encoding="ISO-8859-1"/>
<xsl:template match="Model">
<svg width="800" height="500">
<g id="Body_Rigid" transform="translate(0, 220)">
<xsl:for-each select="Body_Rigid">
<text x="{position()*145 + 40}" y="-70"
style="font-family: arial; text-anchor: middle;">
<xsl:value-of select="@label"/>
</text>
<text x="{position()*145 + 40}" y="-55"
style="text-anchor:end;">ID = </text>
<text x="{position()*145 + 60}" y="-55"
style="font-family: arial; text-anchor: middle;">
<xsl:value-of select="@id"/>
</text>
<rect x="{position()*145}" y="-100" height="70"
width="115" style="fill:none; stroke:black;"/>
</xsl:for-each>
</g>
</svg>
</xsl:template>
</xsl:stylesheet>


-------------------------------------------------

The output is an XML file that contains svg elements, rectangles
representing bodies.
I'm completely at loss on how to represent the connection between body
1 and body 2.

Has anyone run into a similar issue? Can anyone share their experience
or a working example where a relationship between nodes was
represented graphically using SVG?

Thanks for your help.
Andrea P.

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.