OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: Comments Appreciated on Magazine Based on XML/XSL

[ Lists Home | Date Index | Thread Index ]
  • From: "Didier PH Martin" <martind@netfolder.com>
  • To: "'XML Dev'" <xml-dev@ic.ac.uk>
  • Date: Sat, 10 Apr 1999 08:24:18 -0400

HI Mark,

Thanks for the answers, this help to understand your experience.

To the question:
treat the database as
one big DOM and transform the nodes we want out, then I have to ask, has
anyone done that? Are there actually any databases out there that hide
behind a DOM interface and present themselves as one big tree of nodes?

Yes and no. Yes there is implementations like Excelon that show the whole
hierarchical database as a big DOM so that there is less steps in the
publication process.
process 1 (without DOM DB)
RDB ----> XML ----->DOM------>XSL------> HTML

process 2 (with DOM DB wrapper)
RDB---->DOM---->XSL----->HTML

process 3 (directly on DOM)
DOM ---->XSL---->HTML

It seems that tools like Excelon are targeted to process 3 and later on to
process 2.

I personally did some benchmark and found a huge increase of performance
with model 3. However, There is an impedance mismatch between the RB model
and DOM model. The former is based on an array (more particularly an
associative array) and the latter as a tree (a tree could be defined as an
associative array of associative array). When a thin wrapper is created on
RDB to present a DOM facade, the speed is about as respectable as other
dynamic page creation like ASP. Other mechanism are lagging in performance
behind ASP (or anything like it). So, for server side processing, the DOM or
any hierarchical DB interface will work. In fact, the XSL could be adapted
to work on other hierarchical interfaces. For instance, actually, the
directory services are hierarchical databases. A XSL processor could be
implemented on the ADSI interface. So, I found that on the server side, we
should talk more of hierarchical db then of XML. XML being a serialized
format and the hierarchical database a model than can be processed by
languages (either procedural or like XSL). Bottom line, after several years
of the associative array model dominance, the hierarchical model comes back.
So on the server, its more a question of database model and interfaces that
languages understand to do processing on this hierarchical DB. DOM is one of
them.

Regards
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.com


-----Original Message-----
From: Mark Birbeck [mailto:Mark.Birbeck@iedigital.net]
Sent: Friday, April 09, 1999 7:13 PM
To: 'XML Dev'; 'Didier PH Martin'
Subject: RE: Comments Appreciated on Magazine Based on XML/XSL


Hi Didier,

> <question>
> Why do you convert the hierarchical database into XML? Is it
> because the
> hierarchical database do not have a DOM interface?
> </Question>

Not quite sure what you mean. Do you mean, why did we go via XML before
we transformed with XSL? Or do you mean, why is there a separation
between the DOM and the database? I'll tell you what we're currently
doing and see if it helps.

The hierarchical database is just good old SQL Server at root, with a
few layers on top, so there is no tight integration between a DOM and
the database. In the version you're seeing we actually make the tags by
string concatenation! It was all written 8 months ago, so go easy on us.

In the newer (unreleased) version we read the data from the database and
use it to populate a DOM tree, and then either transform it with XSL and
export the result, or just pass it through.

So if your question is the first - why go out to XML before bringing it
back in again to transform with XSL - then it's just because it's old
code and the new code does go straight into a DOM.

On the other hand, if you're implying that we just treat the database as
one big DOM and transform the nodes we want out, then I have to ask, has
anyone done that? Are there actually any databases out there that hide
behind a DOM interface and present themselves as one big tree of nodes?
I've done just that at the level of treating a web server as a great big
node store and using XQL to dig out 'documents' - that's how the next
release of the magazine will work -  but it would be really interesting
if the DOM/DB integration has been developed further.

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@iedigital.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)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS