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

[Borden, Jonathan]

What I am talking about is an interface to a database. The question is:
should we use an interface such as ODBC, JDBC or a proprietary interface
(each vendor has one), and/or the DOM. It has been suggested that when the
database is to represent an XML repository of some sort, the DOM may be one
appropriate interface onto this repository. In particular object database
vendors such as ODI and Poet who are offering XML databases may choose to
offer a DOM interface onto the database. Relational database vendors such as
Oracle may also choose to offer DOM interfaces onto the database.

It has been stated that this is a misguided approach, and that what is
needed is object orientation.

My response is that this is comparing apples to motorcycles. Modern systems
are described at different levels and this is a useful way to organize this
discussion which is in danger of becoming incoherent. Many current systems
are described in terms of three broad tiers: a client tier, a middleware
tier and a server/database tier. When these systems are designed, there
exists a need to interface the tiers. When business rules exist on a
middleware tier, and these rules are designed as a set of components or
objects, these 'high level' objects which contain domain specific knowledge,
have a need to communicate with the database tier. Frequently a set of data
access objects is defined to facilitate interface with the database.

We are talking about different levels. Not for a moment am I arguing with
the need for business rules. The question is how these object rules should
access the database. In modern middleware/transaction processing systems,
the idea is to 'dumb down' the database and place the knowledge in the
business rule layer (which is above the data access layer). Two tier systems
mix the business rules with the data, this leads to inefficiency. A three
tier system separates the business rules from the data. Yet low level API's
such as ODBC or vendor specific API's tie the business rules to the
particular database engine. With proper object orientation, and use of
encapsulation, it is best to uncouple the business rules from the particular
database.

In other cases, a data access object layer is used to couple a 'high level'
or scripting language to a low level binary wire protocol. For example,
Microsoft offers ADO with its Recordset. I suggest that the DOM is no less
capable of modelling data than a Recordset, where a Recordset is optimized
to deliver tabular data, the DOM is optimized to deliver tree data. Perhaps
you don't like the DOM and have a better tree API ... great! let's see it
and then if everyone agrees that it is indeed better, it can be DOM 2.

The concept of the 'object repository' or 'enterprise repository' includes
the idea that code and data can be mixed together in a large bucket. These
systems tend to have difficulties in high transaction volume applications.
They have tended to be overly complex and hence overly expensive for this
reason. At the same time the proper 3 tier web application (browser client,
HTTP server/middleware, back-end database) has really taken off in the last
couple of years (ask Dell :-) By maintaining a distinct business rules layer
from the data access layer, the system can be more easily organized and more
easily modified. This leads to higher reliability and lower cost. These are
good things.

So lets compare apples to apples. Which data access API do you wish to use?
This API is specifically required to be used by business rules to access
data stores.

Paul Prescod wrote:
>
> Right. XML is a serialization. The DOM is an abstraction of a
> serialization. Not an abstraction over your data.

	With objects, the data and code are tied together, we have the idea of a
'live' object and a persisted object. The idea of activating a persisted
object means that the persistant object data (e.g. a file) is parsed to
restore object state. A DOM object isn't so much an abstraction of a
serialization as it is a live 'bucket' of XML data (it is a simple data
access object).

	Business rules operate on data objects in the same way that a JavaScript
program can use a DOM object to process some information.

If your "problem" is
> representing debit card bank accounts the proper abstraction over that is
> "bank account" or "currency account". The *wrong* abstraction is "elements
> and attributes."

	Comparing apples to apples, the DOM has elements and attributes, and a
Recordset has rows and columns. Most bank accounts in the world today are
well represented as rows and columns. There are times when the slightly more
complex concept of elements and attributes has a better impedance match to
the data being modelled than rows and columns.

>
> XML is very simple. "All the world's data" is very complex. That's why we
> need XLink, RDF, HyTime and a bunch of other stuff. If your API to "your
> data" is simply the DOM then you are temporarily hiding its complexity
> behind a simple layer that can *NOT* express its "linkedness", its complex
> class relationships, is geographical 2D-ness etc. I don't know your data.
> I don't know what makes it complex but if your job is interesting it IS
> complex and the DOM does not help you to manage that complexity.

	That's right, that's why *I* need to model my domain using *my* business
rules. And assuming I don't want to code my own database, I need an API that
allows me to store my stuff.


>
> >         It is a big mistake to assume that XSL is only to be
> used for 'styling for
> > the Web or print'. DSSSL as we know is based upon or employs
> Scheme. Scheme
> > is a full fledged programming language, a dialect of LISP. XSL
> does not have
> > the Scheme counterpart to DSSSL, rather it is itself its own programming
> > language (albeit currently simplistic).
>
> XSL is not a programming language according to the Turing/Church
> definition.

	Perhaps not yet, but if I want to automate transforms, XSL or the
transformation language subset 'XTL' is a leap in the right direction. A
large part of computer programming consists of interfacing one API to
another. I'm not saying that XSL helps with this at all but pointing out
that transformations and impedance matching is an important task. If we have
the ability to express transforms directly this greatly reduces the need to
do traditional coding and bit twiddling.

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


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)