Re: UrShape XML parser

[John Palmieri <johnp martianrock com>]

Oh, you do want to use C++.  Ouch, I just thought you were just thinking in
C++.  As much as I love C++ I think that forcing the maintainers to switch
might not be a good thing.  If I have learned anything for developing with Open
Source is to always follow the coding practices of the original developers
unless they ok'ed the change.  I understand that xml++ would be great because
of the ability to override nodes but I just think in the long run C++ is the
wrong way to go with this.

--J5

"James K. Lowden" wrote:

> 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
>
> _______________________________________________
> Dia-list mailing list
> Dia-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/dia-list