Comments Appreciated on Magazine Based on XML/XSL

[Mark Birbeck]

Paul wrote:
> Excelon implements a DOM interface to XML documents, not to
> arbitrary data objects. That doesn't make it a bad product, 
> but I don't think it is the product Mark is describing. I imagine that

> the (imaginary) product that Mark is describing would allow you
> to specify your objects in IDL, manipulate them as ordinary
> object/method/property Java or C++ objects and get a DOM interface
> to them "for free" when you want it. I don't think that that product
> exists.

That's true, Paul, thanks.

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

would retrieve all 'article' objects with an author attribute of 'Mark',
that are children of a node of type 'documents'. This would then be
returned to the caller as an XML document, but with a stylesheet PI
pointing to 'stylesheets/article.xsl'. (Replacing .xml with .htm would
yield the same results but the XML and XSL would be combined for you on
the server.)

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.

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!'

Regards,

Mark

Mark Birbeck
Managing Director
Intra Extra Digital Ltd.
39 Whitfield Street
London
W1P 5RE
w: http://www.iedigital.net/
t: 0171 681 4135
e: Mark.Birbeck at iedigital.net


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at 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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)