On Mon, 2004-03-01 at 05:11, Rodrigo Moya wrote:
> it is designed to cope with any data source, even with hierarchical
> data. There might be some stuff missing, but data models (recordsets)
> can contain fields of type 'list', which contain lists of values, and
> those values can in turn be more lists, and so on. So it should cope
> with hierarchical data also.
Hmm.. that does sound interesting.
> I'm not sure though if libgda is the correct solution for inkscape XML
> parsing.
Probably not -- since really it's more a question of storing XML in the
database, than storing the database in XML. I'd want to work very
directly with libxml2 (and for CSS, libcroco) for parsing.
> > 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.
> 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?
-mental
Attachment:
signature.asc
Description: This is a digitally signed message part