Simple approaches to XML implementation
Peter at ursus.demon.co.uk
Sun Mar 2 11:46:49 GMT 1997
In message <199703021056.LAA02919 at florix.rz.tu-clausthal.de> Ingo Macherius writes:
> I wrote the Perl interface because I needed an access to SGML information which
> is fast enough for CGI. So I maintain the information base as SGML doc and
> "render" it to my homegrown OODB described in the last mail. The information
One of the selling points of XML should be that it maps directly onto OODBs.
I don't know much about this myself, but I would assume that since the OODB
supports persistence then this is a way of supporting persistence in XML
applications. (Hope this isn't drivel).
> is updated only once a week or so, so this is a sufficient method.
> Jade is too slow, considering the fork the http has to do to start
> DSSSL processing. I'd love to use SDQL !
> > > > I found this sufficient to solve small problems for which ESIS is not enough
> > > ^^^^^^^^^^
> > > I think you were operating _on_ the ESIS stream. You mean that simple
> > > 'grep' or other tools weren't powerful enough?
> I need a persistent representation of structured data. The information would
> fit into a RDBMS, so the job could easily be done with mSQL. But I wanted to
> find out, if SGML would works, too. It does :)
> Yes, I operate on an ESIS stream while *rendering* the doc to my OODB, but
> afterwards I operate only on the DB for speed's sake. I'd prefer to do this
> on a persistent grove, but implementation would be far more complicated than
> my little perl hack :)
Again - I suspect that getting the XML/OO interface correct means that we
get gains from both sides.
> > > > between navigating (father/son) and id-based lookups (fetch).
> This is very important for me, because sometimes I *know* which element I
> need, because I get the ID from elsewhere. Any API to XML should offer both,
> a navigating query and a mere GOTO.
My simple understanding is that TEI pointers offer all of this. They have
an (SGML) ID which is your GOTO and a sufficiently powerful navigation
system for (my) needs. The description is in the PhaseII documentation
but has not yet been discussed by the WG or ERB. I am hoping that they come
up with something very similar to TEI, since I can understand it!
Here's a simple example from the draft:
ID (a23) DESCENDANT (2 TERM LANG DE)
matches the second TERM element with a LANG (attribute) of DE occurring
within the element with an ID (goto) of a23. TEI should be able to
deal with everything that you have so far specified.
I have asked very recently whether there is an implementation of this
and maybe part of this topic will move to the TEI thread. I suspect that
a key question will be performance and therefore it may be important to decide
whether a document is indexed when parsed (suggestions?) or whether
intermediate search results are cached. Without more experience I won't
speculate. My own primitive system caches results (e.g. once a question
is asked about IDs, it will remeber the ID values in a hashtable for future
To the experts:
I have read the core SDQL and it seems to have a different syntax from
TEI. So are the two going to be used together? What does SDQL offer
that TEI doesn't (to a simple web hacker?).
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (rzepa at ic.ac.uk)
More information about the Xml-dev