Re: Shapes layout proposal, XML Schema

[Andre Kloss <kloss rbg informatik tu-darmstadt de>]

> > John/James L./Andre:
> >
> > I like (and have argued for) the idea of a 'mini-DOM' API, based on a
> > subset of SVG, being used as the internal structure of these Ur-Shapes.
> > For the arbirary additional properties, we need a portable,
> > language-agnostic set of datatypes, which can come from XML Schemas.
Agreed. I have read some docs about them and I like XML Schema. The
only problem here is that we have no Schema-validating parser.

> > (Note: the types in the schema spec are acutally fairly close to those
> > in the Dia std. props library, with the exception of the UI elements, so
> > much of the code can probably be adapted from there and/or made to work
> > with std. props objects).
> Can you give me a URL to the Schema specs?
www.w3.org/XML/Schema should do the trick, much resources linked from
there.

> > [Callbacks...again]
> Again I think we are getting ahead of ourselves with callbacks.
Yeah, let's first do the stuff we need to get the thigs on screen,
then we can do customization/specialization stuff.

> I think the custom shape code should be used as a reference but
> since we would be gutting the internals anyway, a new object
> should be created from scratch possibly using some of the shape
> code.  I would like to add it as a drawing primitive of dia-canvas
> since that is where dia seems to be moving.
Agreed. I think us doing the coding from scratch is easier than
thinking into the custom shape code.

> [no difference to the end user?]
> The internals are going to be different to accommodate layout and
> properties.  A mini-DOM interface will be added along with any classic
> interface that needs to be present for dropin compatibility.  Hmm, I think
> external .so's .dll's and python scripts would be a good thing.  In most
> cases the behavior code would be specific to editing in Dia but one could
> take a diagram, bind a new script to it and create a completely new
> program.  For example a program that takes a circuit diagram written in Dia
> and runs a simulation on it.  As for portability that would be up to the
> author of the callback libraries.  Again that is all future work.
That's what I want to do with ConStruct. (http://con-struct.sourceforge.net)
But I'll keep the interpreter outside of Dia. That's what I need the
parsing stuff for.

> [C++?]
> I don't think C++ will be the implementation language I just think James
> needs to think in C++ terms to understand the problem at hand.  I will
> convert that to UML and all will be right in the world.  I think using some
> code from Gill and/or Sketch would be nice for the SVG parsing so that we
> might be able to support most of SVG.  Like I have stated before I think
> having the ability to use the full SVG spec allows people to import complex
> objects when appropriate.  Right now we are going to stick with a subset for
> simplicity but in the future...
I never balked at C++ being the language of choice. I am comfortable
with C, even if in an object-oriented manner of coding. As for using
more of the SVG specs, this is outside my bounds.

> > Lennon Day-Reynolds
> --J5
cu Andre
-- 
Tolerance rulez, everything else sux! -- Andre Kloss