[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Simple approaches to XML implementation

• From: Peter@u... (Peter Murray-Rust)
• To: xml-dev@i...
• Date: Sun, 02 Mar 1997 11:14:53 GMT

In message <199703021056.LAA02919@f...> 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 !

See below.

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


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

	P.

-- 
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences
http://www.vsms.nottingham.ac.uk/

xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@i... the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@i...)

• Prev by Date: Re: Simple approaches to XML implementation
• Next by Date: NXP
• Previous by thread: Re: Simple approaches to XML implementation
• Next by thread: Re: Simple approaches to XML implementation
• Index(es):
  • Date
  • Thread