Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Storing Lots of Fiddly Bits (was Re: What is XML for?)
"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@i...
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@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
