xml-dev - RE: Comments Appreciated on Magazine Based on XML/XSL

["Jonathan Borden" <jborden@mediaone.net>]

Mark Birbeck wrote:
>
> I was also imagining that:
>
> - when I want the last node from a tree that contains 100,000 nodes
>   that the whole 'document' would not be read into memory.
> - that I could access the tree as if it was a complete DOM with
>   all the caching and so on being done for me.
> - that if I perform an XSL-type query I will get the nodes I want,
>   regardless of whether they are in memory or not.
>
> I have implemented a very crude version of this. I use the IE5 DOM and
> with this I retrieve documents from our database using URLs that are a
> scaled down version of XQL (I can't say I like XPointer). For example:
>
> 	http://[server]/documents/article[@author='Mark']/article.xml

	Mark, as Didier mentions, this is an interesting request. In this case,
does the document itself need be stored in a database (as opposed to a file
'article.xml') or do you intend to maintain metadata in a directory
structure?

	Is the request, then, for a directory with a XQL interface? or have you
implemented this already? (I'm having some difficulty determining what you
have already implemented versus what you are ideally requesting).


>
> The problem with this is that I have to convert this request to a query
> on the objects in the hierarchical database in order to populate my DOM.
> Of course, once in the DOM I can export it as XML or transform it if
> necessary, so the database does look from the outside like it is one
> great big XML document.

	For example, eXcelon has an XQL interface so no conversion is required
(though you need to convert your $$$ into the licenses :-(

>
> But although I am quite happy with this so far, I can see that you would
> have to code this up for every type of database, and really it should be
> a job for the DOM. It really needs a layer like the layer above the
> database-specific layers in ODBC; it would sit just below the DOM. This
> layer would obviously need to understand schemas, so it wouldn't be a
> trivial task to implement.
>
> Anyway, my original question was 'is anyone doing anything like this?'
> and I think the answer is 'nowhere near yet!'
>

	I've done a bit of work converting schemas back and forth between ODBC/SQL
queries using XSL transformations. My latest medical repository (HL7 object
model) uses a relational back-end with XSL transformations to convert to and
from XML documents. I haven't (yet) put an XQL layer on this (the current
layer is an XML representation of SQL queries. If anyone has done work to
convert the XQL string into an XML intermediary, it should be possible to
convert that into my XML SQL representation via an XSL transformation as
well. Would this help?

	i.e. what I propose is:

	XQL <-> intermediate XML representaton <-XSL-> XML SQL
representation -XSL-> SQL

	Although I have done work using native DOM wrappers on databases, you still
need an XQL engine. If the db schema can be represented as relational
tables, queries are optimized. The problem is that each level of the
hierarchy maps to a relational join (with a unique identifier primary key).
At least that's how I do it. Does anyone have a better solution that can be
shared?

Jonathan Borden
http://jabr.ne.mediaone.net


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)