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

["Borden, Jonathan" <jborden@mediaone.net>]

Paul Prescod wrote:
>
>
> "Borden, Jonathan" wrote:
> 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.

	Yes we can agree (wonders never cease :-) hope you don't mind my dragging
this debate out, but I believe it is an important issue. Some estimates
suggest that corporate programmers spend up to 60-70% of their time dealing
with database interface issues.

>
> > 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.

	Performance will depend on implementation. As SQL or OQL is in the core of
the database engine, XQL can also be placed. Query optimization strategies
apply. For example Oracle 8i is reportedly placing an XML DOM parser in the
database engine. What this will mean for performance I don't know but I
suspect that the XML people at Oracle are considering these issues.
XQL being a Microsoft et al. proposal suggests that Microsoft is also
considering these issues. I would hazard that IBM is considering this as
well. I suppose we will at some point see what they come up with. If it
works well, I'm correct, if not you're correct.

>
> >         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! *************
>
	Whoops! I miswrote. I mean to say, there is no standard, *widely
implemented*, language independent interface to ODBMS's. Certainly OQL and
ODMG standards exist. However, when I've looked at ODBM's they require
vendor specific interfaces/code. In contrast, I can generally plug in an
ODBC driver and switch from Oracle, to DB2 to SQL Server (etc), without
changes to the client code. This is a true interface. True the syntax of OQL
is standardized, but the mechanism of interaction with the ODBM's is
generally vendor dependent. That is to say, SQL is the language standard but
ODBC (or JDBC) is the binary interface.

	What I want is a simple way for a server based script (e.g.
JavaScript,Python) to interface with a database. ADO and OLE-DB are an
effective recordset object layer which allow access to tabular data from
server scripts (e.g. ASP). The use of the SHAPE command allows hierarchical
recordsets. These recordsets can be transmitted back to the client via a
custom binary marshalling interface or XML with just a tad of work.

	How can I do this using OODBM's and OQL (last I checked there is no
scripting interface)? This is a basic e-Commerce function.

>
> >         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 wish to make a distinction between DOM Level 1 which IMHO is lacking in
some notable features particularly in the ability to generate trees etc.
Vendor specific extensions, notable Microsoft's include the ability to run
XSL queries against DOM trees. I employ this as a lightweight browser based
local, in-memory database (scriptable). In IE5b2 "selectNodes" is part of
the IXMLDOMElement interface (a M.S. extension), not the IDOMElement
interface.

>
> 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.

	Yes a serialization problem and an example of how XML can be used to
represent arbitrary object data. COM unlike CORBA does not provide an
automatic persistence function. XMOP is a persistence interface for COM
objects which does not require the object to know about serialization (it
need only have a typelibrary).

>
> >         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.

	Just to point out that the XML (and DOM) data model can solve certain
problems which aren't trivially solved in the relational mode. No big deal.
This is also easily solved by OODBM's.

>

Jonathan Borden
http://jabr.ne.mediaone.net


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)