xml-dev - Re: Simple approaches to XML implementation

[Ingo Macherius <Ingo.Macherius@tu-clausthal.de>]

Peter,

> > > 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.

	++im
-- 
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 majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)