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

[Paul Prescod <paul@prescod.net>]

"Borden, Jonathan" wrote:
> 
> > 3. Therefore we should pretend that relational databases are really DOM
> >    trees.
> 
>         no. if the data is tabular then use a recordset. in the specific cases when
> 1) we are storing data which is naturally hierarchical. 2) when the data
> needs to interface with systems which for other reasons employ DOM
> interfaces 

Okay. We can probably all agree with this. If you have software that is
expecting a DOM and you need to connect it to data that is not XML, you
need to build a DOM interface. This is a different point of view from
those who say: "let's build new client software using only the DOM served
by data with only a DOM interface. The fact that the DOM is standardized
will just make all of my interoperability problems go away." No way. If
your client software and your server software had an impedence mismatch,
slapping a DOM interface on both sides makes it *worse* not better.

> e.g. my XSL processor us built on a DOM interface and I wish to
> query the database using XQL (which happens to be built into my XSL
> processor in this example), it is more convenient to interface to the data
> using DOM interfaces than it is using recordsets (i.e. tabular data).

It's more convenient but it's probably going to run as slow as hell.
Nobody implements SQL or OQL on top of an industry-standard interface.
They put it right in the core engine of their database.

>         Arguably, when using an ODBMS this example would be more straightforward
> (but you picked RDBMS). The problem is that there is no standard, language
> independent interface onto ODBMS's. 

********** Yes there is! *************

It isn't as widely hyped as XML/DOM. I haven't written a book about it
(and hardly has anyone else). But the standards *do* exist. Check
http://www.odmg.org. There are well defined APIs, bindings in a few
languages, a solid object model and a query language. It's all in there.

My fear it that these technologies will get lost in the XML hype.

> The DOM, while not the perfect interface
> *is* standard, and this is the big utility.

The DOM is a standard for accessing XML, HTML and CSS information. It
isn't for modelling arbitrary business objects. It wasn't designed for
that and it isn't good at that.

>         For example, I get to say (using 'extended DOM'):
> 
>         NodeList anotherSet = airplanes.selectNodes("airplane[@color='red' and
> .//screw/thread/@pitch = 64]");
> 
> to select all red airplanes with screws having a pitch=64...

The DOM is doing essentially nothing here. This imaginery XML query
language is doing all of the work. But even the XML query language is
going to make solving your problem harder than OQL would. For instance OQL
can be statically type checked. XQL cannot, in general, for many subtle
reasons. OQL can handle mathematical range constraints. OQL has a concept
of a "stored query" that allows some level of abstraction. OQL has "local
variables" also for abstraction.

I don't completely follow your examples:

>         XMOP for example (http://jabr.ne.mediaone.net/documents/xmop.htm) is a way
> to serialize arbitrary COM objects using their typeinfo metadata. XMOP is a
> layer that can persist objects into either a) a stream (serialization) b)
> direct-to-DOM. When I attempted to design a direct-to-Recordset persistence
> interface on XMOP I found that I had to essentially develop a
> DOM<->Relational mapping. This is because arbitrary objects can be modelled
> in a hierarchical fashion (e.g. serialized to XML).

This seems like a serialization problem. We all agree that XML is great
for serialization. If your only goal was to get the data into a "database
of some kind" then an OO database would have been easier than an XML
database.

>         In another example, using the medical imaging DICOM protocol (a complex
> property based protocol) I have developed a mapping to the Microsoft
> PropertySet format (used with Index Server). This mapping is not clean (at
> all given the inability to represent certain DICOM structures as
> PROPVARIANTs). This causes similar problems in mapping the protocol to a
> relational database (the workaround is to use binary data). Using XML and
> the DOM was a piece of cake to solve this difficult problem.

I'm not at all clear on how the DOM solved this impedence mismatch.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco

"Remember, Ginger Rogers did everything that Fred Astaire did,
but she did it backwards and in high heels."
                                               --Faith Whittlesey

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)