Re: UrShape XML parser

["James K. Lowden" <jklowden speakeasy org>]

All,

I spent today researching the technologies we're using and considering.
I've come to some conclusions that need peer evaluation.  I'm going to make
some bald assertions for brevity; please infer your own "as I see it" and
"to the best of my knowledge" wherever you think weasle words are
appropriate.

1.    The UrShape is an empty container, an XML file whose elements are
empty.  From Dia's point of view, we read an UrShape into memory, plunk it
on the canvas, and make it part of Dia's in-memory diagram representation.
We let the user populate it with data, stretch its dimensions, whatever.
When it comes time to write it out to disk, it had better behave a lot like
every other Dia shape, or at least like a collection of them.

2.    "mini-dom".  I'm beginning to think Lennon is either completely right
or completely wrong.  Why "mini"?  For the purpose of managing the data in
the UrShape, and for the purpose of traversing the tree of (potentially
nested) members, why not just DOM and be done?  I do not suggest we discard
everything that came before.  To the contrary, to the extent an UrShape can
be treated like an SVG shape or a StdProps one, it should be.

3.    Mark well, you heard it here first: I have determined the complete
set of things that will ever need to be represented in an UrShape.  They
are:

    A)    SVG shapes
    B)    gtk widgets
    C)     XLinks

These things need their relative location described (what everyone keeps
calling "layout", right?), as well as their visibility, color, layer.  The
DTD should provide for all of these and nothing more.

Some people want to see a fuller/complete implementation of SVG, which is
OK by me, FWIW.  The UrShape should use James's SVG shape code, though,
because we get immediate bang for it.  Better to improve (what is it we're
not allowed to say here?  "Embrace and Extend", yes?) the SVG shapes and
let the whole system benefit.

4.    We want the UrShape to resize according to the data it displays.
Unlike the SVG shape, it cannot have fixed x,y coordinates.  How do we
propose to denote the origin of member B relative to A, knowing only A's
origin and not its height and width?

5.    I promised a C++ header file, and I offer both more and less: an
existing implementation that is at least a good starting point, libxml++.
Cf. http://lusis.org/~ari/xml++/.  About the only thing I don't like about
it is that the opening curly braces of the functions aren't placed on the
left margin.  Otherwise, it looks pretty good.  We'll want to derive from
XMLTree and XMLNode to add UrShape-specifics.  If you don't want to
download it yourself, please look at the README at
http://www.schemamania.org/dia/libxml++/.  Best feature: instantiate a tree
providing a filename argument, and start traversing the nodes.

6.    C++ will fit right into Dia.  I don't propose to re-write anything or
re-design anything or re-implement anything.  I propose to write a generic
UrShape handler module to deal with user input and canvas behavior in C++.
Where C semantics are called for to connect to the system, that's what I'll
provide/use.  IOW, I'll treat Dia like I treat the OS: as something that
needs C calling semantics.

7.    I realize C++ has great advantages to the C++ programmer and none to
anyone else.  To the C++ programmer who wants to specialize the behavior or
some particular UrShape, all that's required is to derive a new class from
UrShape and override particular member functions.  That's nice.  What's not
so nice is that people who want scripting embedded in the UrShape or want
to drive it from some external program are stuck without equivalent C
functions to latch onto.  That's what I call a Good Problem (tm).  We
should be so fortunate that the UrShape is so successful (having meanwhile
assumed its completion) that the world at large demands
-- Demands! -- more functionality.

8.    Isn't LXR just wonderful?  Just thought I'd toss that in.

+++

I still have a steep hill to climb to assemble the skills and master the
Dia code before I can even think about integrating this grand idea into
Dia.  I thought this little note of intention and direction might save me
some wasted effort and test my thinking.  What have I overlooked and what
do I fail to appreciate?

Andre, I'm particularly interested in your thoughts, since you seem the
most eager to wade in.  Lennon, how does the DOM thinking sound to you?
And John, have I said anything that affects your DTD?

Oh, one trivial thing.  When referring to me in the third person, it might
be better not to call me "James" even though that's my name and I like it
very much.   Perhaps it would be as well to refer to me as "jkl".  Not that
I'd suppose anyone would confuse Mr. Henstridge's work with mine; I just
don't want anyone to work any harder than necessary to follow the
discussion.

Thanks for listening.


--jkl