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

[Stephen D. Williams]

I really believe, at the moment, that my ultimate database would have XML based tables and
allow relational (possibly even SQL) queries along with an XQL/XML-QL structured queries.

Normalization could take several forms and allow non-normalized or threshold normalized forms.

Of course the SQL-XML view on things would not have full XML structuring capabilities, it
would provide a great bridge and in fact solve quite a few annoying problems that RDBMS's and
OODBMS's haven't really solved satisfactorily: schema migration and flexible schema's.

I have some ideas, but I'm going through some references to see what I'm missing right now.

sdw

Paul Prescod wrote:

> "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 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)


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)