Lists Home |
Date Index |
- From: Ingo Macherius <Ingo.Macherius@tu-clausthal.de>
- To: Peter@ursus.demon.co.uk
- Date: Sun, 2 Mar 1997 11:56:10 +0100 (MET)
> > > I have made up a perl5 module which models a very simple forest-like strukture,
> > > that holds Perl5 objects. The objects are created by reading nsgmls' ESIS
> > > I think this may be called a poor-mans-grove :) I made up a simple API:
> > ^^^^^^^^^^^^^^^
> > It's still very powerful, and you have recognised the importance of
> > structured documents. The good news is that this will all be addressed
> > (literally and metaphorically) in the discussion of addressing within
> > XML documents. The TEI project has developed a pointer scheme which
> > covers most aspects of structure and extends the metaphor to descendants,
> > ancestors, siblings and navigation by attributes and their values. I
> > am expecting one or more 'black boxes' to be developed which support this,
> > so that you don't have to write perl scripts any more. I'm waiting to hear
> > from another thread :-)
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
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 :)
> > > really didn`t get the details. But what I found valuable is the choice
> > ^^^^^^^^^^^
> > I think it's very important not to be frightened by 10179. What you have
> > done is very similar to what I and many others have done - devising
> > home-grown tools for searching structured documents. 10179 has an
> > implementation in Scheme (am I right?) but not in more procedural or
> > object-oriented languages.
Hm. I always thought DSSSL is a dialect of Scheme, so this is not q question
of implementation. IMHO it *must* be implemented as scheme. It's allowed to
define other languages that map on corresponding DSSSL/scheme statements,
which have to be submitted to a DSSSL engine. But an engine that calls itself
a DSSSL engine must have a (restricted) scheme engine inside. Correct me
if I am wrong !
I'd be happy to hear about anyone writing a book on DSSSL. I read all examples
I could get from jjc and Jon Bosak, but a structured introduction would help
to convince other people, that do not have the time to read sources.
> > > 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.
Snail : Ingo Macherius // L'Aigler Platz 4 // D-38678 Clausthal-Zellerfeld
Mail : Ingo.Macherius@tu-clausthal.de WWW: http://www.tu-clausthal.de/~inim/
Information!=Knowledge!=Wisdom!=Truth!=Beauty!=Love!=Music==BEST (Frank Zappa)
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (email@example.com)