Re: XML

[John Edstrom <edstrom teleport com>]

On Sun, Feb 02, 2003 at 04:11:41PM +0000, Aaron Trevena wrote:
> > From: John Edstrom <edstrom@teleport.com>
> > On Fri, Jan 31, 2003 at 11:40:24PM -0600, Lars Clausen wrote:
> > > On Fri, 31 Jan 2003, John Edstrom wrote:
> > > > I'm thinking of spitting out some data as digraphs.  I looked at the
> > > > xml output from simple graphs and think that I can figure it all out,
> > > > but I'd rather spare myself the learning experience.
> > >
> > > Have you looked at the various programs available in the Links section of
> > > the webpage?
> > >
> >
> > Yes, but only briefly.  I"m still just casing the joint at this point.
> > AutoDia is the closest that I've seen to what I want, but I'm not
> > really interested in UML.
> 
> Cool - what else would you be interested in. I happen to be hacking
> autodia this weekend and am working on dia->graphviz and vice versa.
> Hopefully I can use similar code/logic to allow graphviz, argouml and dia
> to interact.

Basically I'm just interested in labeled ellipses connected by labeled
lines having an arrow on one end.  Very simple stuff.  The perl Graph
package has a dot writer class that generates dot files OK.

So far my biggest concern with a dot2dia transformation is that dot
uses splines and dia doesn't.  Some of dot's edges get pretty baroque
in complex graphs and arcs and polylines can't do equivalently
tortuous paths as well.

> 
> As far as most of the autodia code is concerned diagrams are just
> diagrams containing nodes and relationships - its should be easy enough to
> add some classes or re-organise the internals so that different diagrams
> with different types of nodes and edges can be produced/processed.
> 
> > Layout is my main concern, more than rendering or manipulation.  I use
> > the perl Graph::Directed module which, happily enough, writes xml
> > and/or 'dot' files ( from the graphviz package).  With the right
> > arguments dot will figure out a reasonably well-balanced layout for
> > the digraph and dump the coordinates of the nodes and edges.
> 
> I have just been looking at this, I have already done some simple
> calculations to work out aproximate coords for dia diagrams that autodia
> uses already.

I considered doing that.  But in arbitrarily complex graphs the
arrangement of the nodes and edges gets difficult.  Dot does a pretty
good job and I figure that it would take a lot of work to do better.

> 
> > I figure it shouldn't be too difficult to convert or rescale the
> > dot-calculated coordinates into dia coordinates which would give me a
> > better renderer of the same graph.  If that's the case then my strategy
> > is to convert from dot >>-> ( xml | xsl ) >>-> dia.xml.
> 
> Hopefully autodia 1.4 will allow for dia ( not laid out) -> dot -> dia
> (laid out). I don't know how much time you have to hack perl - but it
> would probably be easier to transform dot to dia using perl than XSLT
> which is unwieldy for most tasks beyond rss to html.

That's probably true.  There is a strong case to be made for at least
a dot2dia standalone module or program.  I haven't had a chance yet to
figure out the best way to partition my particular problem.  I'm only
shopping around at this point.  FWIW, here are my thoughts so far:

This graph thing is only a part of a larger project.  The core object
is an automaton/digraph which will be subclassed for other purposes;
the graph will govern the evolution and behavior of the object
inheriting it.  The display part is strictly secondary, only as a
convenient method to see what the machine looks like and not have to
debug structure by reading oodles of text.  Also there is a
possibility of a gaphic constructor so that complex machines can be
designed by dragging & dropping sub machines into a larger composite
automaton.

The object itself will be described, stored and maninpulated via XML.
So there will be a definitive XML description of the digraph part of
the object available to begin with.  So, for rendering, the first step
will necessarily be an XML ( | XSL ? ) >>-> something transform of
some sort anyway.  What attracted me to dia in the first place was its
ability to accept XML.

It may also be desirable to be able to import externally derived
machine designs into the object and I see that being XML as well.  If
I go with graphic machine design I'll also want to import the result
via XML.  The object will have an xml_graph_in method which will
ignore all graphic information and an xml_graph_out method which will
emit no graphic information.  An XSL filter would work well at this
interface, I think.  That way dia could be used to edit the machine
and not just rendering it.

All that I'd need for rendering are some reasonable metrics for the
overall layout.  Right now I'm thinking that since an XML|XSL
transform of just the nodes and edges to dot is simple then a good way
to go would be to have a dot2dot transform pipe which would add the
layout metrics to the nodes and edges and then, using perl, I'd just
normalize those integer coordinates to floats between 0 and 1 and then
put that normalized abstract layout into XML. Then that layout would
be exported to almost any other format by renormalizing to whatever
coordinate system the target needs.  The actual arithmetic would
almost certainly be done best in any XML-aware language rather than
XSL.  But I think that the other stuff is probably best done with XSL
since each target will have different constraints.  For example, dia
knows about shapes, but not about nodes while, dot uses nodes where
the shape is just an attribute of the node.  I have no idea what other
packages may require.  I'd also like to see the final rendering be
driven by XSL and that step would control minor things like line type,
line thickness, color, font, etc., maybe more such things that will
change often and oughtn't require recoding the perl module.  At this
point I can't say where rendering will take place. Possibly in a java
applet, maybe an FO transform to pdf... who can say.  I just don't
want to restrict options at this point and XML is good for that.

That's how I see XML fitting into the Great Scheme of (my) Things.

> 
> Anyone wanting to discuss dia related tools like autodia might want to

That may be a good idea.  Its already drifting away from dia per se
and perhaps should be continued elsewhere.  I'm only responding here
because I figured that dia folk may be interested in knowing how
outsiders are thinking about dia.

> email me off list, as I would like to set up a site / list for such
> topics. I hope that connecting users and develoeprs of graphviz, dia,
> argouml and the like would make for cooler tools and better integration.
> Failing that I can just use everybodies code in my plan to take over the
> world *cough*.
> 
> regards,
> 
> A.
> 
> -- 
> Aaron J Trevena - Perl Hacker, Kung Fu Geek, Internet Consultant
> AutoDia --- Automatic UML and HTML Specifications from Perl, C++
> and Any Datasource with a Handler.     http://droogs.org/autodia
> 

-- 
John Edstrom