Re: [Inkscape-devel] Joining GNOME Office

[Rodrigo Moya <rodrigo gnome-db org>]

On Mon, 2004-03-01 at 20:29 -0500, MenTaLguY wrote:
> 
> > > Also, there are some special requirements, like a commit operation that
> > > returns a log fragment which later can be rewound/replayed to undo or
> > > redo the transaction (this is used for undo/redo of operations that
> > > affect the parse tree), and fine-grained constraints and change
> > > notifications.
> > > 
> > this is already available in libgda in the form of transactions. A XML
> > provider (= plugin) could be implemented, and have it implement the
> > transactions internally.
> 
> It sounds like we'd need a very specialized provider; unless I
> misunderstand, most existing providers would not give you multiple
> levels of "undo", or in general the ability to reverse (and replay) an
> already comitted transaction.
> 
some providers already support that, in the form of nested transactions.
Others would have to simulate it in some way. For the XML provider, if
done, it would just mean keeping track of the changes, and of the undo
levels, to be able to rollback a set of transactions.

> > In fact, we already have a XML-based provider,
> > although it is supposed to only support libgda's export/import XML
> > format (a DTD we've got to describe a full database).
> 
> I'm not sure that helps much -- in our case, we want to store the XML
> (and other grammars too, in the same tree, as one unified AST) in a
> database; the form of the backend doesn't matter quite so much.
> 
> Here's a concrete example of what I have in mind.  Take the following
> SVG fragment:
> 
>  <g>
>    <rect x="0" y="0" width="100" height="100" 
>     style="fill:red;stroke:black"/>
>    <use xlink:href="#foo" />
>  </g>
> 
> The AST would look something like this:
> 
> Key: [1] - numbered continuation points so the diagram won't wrap
>      (ClassName) - a mutable node of a given class
>      "blah" - an immutable string node
>      ( "axis", "name" ) - a branch name (a branch can hold one or
>                           more children)
>      {SVG}g - shorthand for an expanded name in the SVG namespace 
> 
>  (XMLElement)--+-- ( "name", NULL ) -- "{SVG}g"
>                |
>                +-- ( "child", NULL ) -- [1]
>                                         [2]
> 
>  [1](XMLElement)--+-- ( "name", NULL ) -- "{SVG}rect"
>                   |
>                   +-- ( "attribute", "x" ) -- "0
>                   |
>                   +-- ( "attribute", "y" ) -- "0"
>                   |
>                   +-- ( "attribute", "width" ) -- "100"
>                   |
>                   +-- ( "attribute", "height" ) -- "100"
>                   |
>                   +-- ( "attribute", "style" ) -- [3]
> 
>  [2](XMLElement)--+-- ( "name", NULL ) -- "{SVG}use"
>                   |
>                   +-- ( "attribute", "{XLINK}href" ) -- "#foo"
> 
>  [3](CSSDeclList)--+-- ( "child", NULL ) -- [4]
>                                             [5]
> 
>  [4](CSSProperty)--+-- ( "name", NULL ) -- "fill"
>                    |
>                    +-- ( "value", NULL ) -- "red"
> 
>  [5](CSSProperty)--+-- ( "name", NULL ) -- "stroke"
>                    |
>                    +-- ( "value", NULL ) -- "black"
> 
> 
> The leaf nodes are immutable strings, so all mutations of the tree are
> accomplished by adding/reordering/exchanging/removing nodes on branches.
> 
> Depending on the class of a node (and on higher-level objects which have
> attached themselves to it), various constraints may be applied as to
> which mutations are valid and permitted.  Every mutation also results in
> a notification to any interested listeners, on a per-node basis.
> 
> [ For example, XML elements have only one "name", which cannot be
> changed, "attribute"s, and "child"ren -- no other branches are valid. 
> Their "child" axis will only accept other XMLElements, and branches on
> the "attribute" axis will only accept one child.  This permits the
> actual representation for XMLElements to be very compact and
> specialized. ]
> 
> Every node is capable of serializing itself as a UTF-8 string, and every
> class has an associated parser (here generally implemented using libxml
> or libcroco) that can be used to build nodes of that class from such a
> string.
> 
> At least that's the design I'm looking at right now.
> 
> (yes, I am utterly insane)
> 
> It sounds like libgda might be general enough to expose a useful
> interface to this kind of setup, but it seems like it'd require a very
> custom backend and probably not all the functionality could be made
> available through libgda's generic interface?
> 
well, libgda could help in the storing and reading of the data from the
database. Not sure if it fits here. If you just want to parse the XML in
a specific way, using libxml2 directly might be better.

What I don't understand here is why you'd want to store all that in a
"database", don't the XML just come from the .SVG files?

cheers