Storing Lots of Fiddly Bits (was Re: What is XML for?)

[Clark Evans]

"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
      big query.
  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
database.  *smile*

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.


:) Clark

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)