Lists Home |
Date Index |
- From: Clark Evans <firstname.lastname@example.org>
- To: "Borden, Jonathan" <email@example.com>
- Date: Thu, 04 Feb 1999 06:13:46 +0000
"Borden, Jonathan" wrote:
> You are missing the point. Since the data is already deserialized, there is
> no delay due to processing. The idea is that the data has already been
> entered into a database which implements a DOM interface (the database is
> free to implement other interfaces as well). I never claimed that the data
> was entered as XML or that a serialized XML document ever existed.
Oops! Sorry about not getting the context
right. *blush* Let me try again.
Anyway, I see one context where putting a DOM
interface on a relational database would be great,
and I see another context where I don't think it
would be too hot.
Interactive "generic" organizational navigator
I did something like this at Ford. I found that
organizational navigation has these characteristics:
a. Only a small fraction of the information
in the database is queried.
b. It is interactive, the system is best modeled
as a bunch of small queries rather than one
c. It is hierarchical in nature (Xrefs are rare)
as the user goes down a branch, you store
all of the primary keys on the stack.
The big problem with the implementation was that the
mapping from a custom relational-database model to
the DOM model is, let's say, non-trivial.
On the flip side, however, things are much more
cheerful. A wonderful, re-usable CORBA/DOM client
could be built (with very good market potential).
This results in great re-use from not only a
software, but also from a training perspective.
Query Extraction Layer
I can also see an XML stream as the result from
a query. In this case, the de-normalized,
hierarchical view of the information resulting
from a nested query is the stuff reports are
made of. I picture the client using XSL on
the resulting stream to generate a report.
In effect, the XML output stream becomes what you
would normally call a view. Then, each "user"
can filter/format the information as they would
like using a standardized XSL based client.
I don't think this is new... and I'm looking
forward to mature technology doing this.
However, I'm not sure about using DOM as an
interface to a relational database in this
context. The way Oracle and other databases
compute large queries with subordinate tables
is, at its heart, stream-oriented. Many of
these databases will "drive" off a single table
sequentially, collecting the information from the
subordinate tables as the query progresses.
Therefore, I picture a DOM implementation
using thousands of nested queries to generate
the same tree that a few large queries would have
handled nicely. In this case, the database
engine would not be able to take advantage
of aggregate indexing and elimination
algorithems. In effect, negating the benifits
of having corporate information in a relational
Anyway, I just can't picture using DOM in this
context as an interface to a relational database.
For this case I feel using a stream-oriented solution
on the server with an object-oriented event processing
system on the client seems the better approach.
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)