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

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

Paul Prescod wrote:

> If I am using a DOM interface,
> it frankly
> > doesn't matter what the serialization format is, I am
> interacting directly
> > with data through an interace.
>
> You are interacting with data through an interface that was designed to
> provide access to the abstract data model of a *serialization*. In other
> words you are treating your database as if it were the result of parsing
> an XML document. You've put an "elements and attributes" interface on data
> that is much more complex than elements and attributes. If it were not
> more complex then elements and attributes we would not need stuff like
> XLink, HyTime, Namespaces and RDF to even *attempt* (and fail) to
> represent it.

	Really !? and I thought I was interacting with an interface designed to
represent the abstract data model of XML. How could we have drawn such
disparate conclusions. I *don't* care what the intention of creating the DOM
interface was BTW just as I don't care what the intention of creating the C
language was. I can use tools, interfaces as I see fit. Does the DOM
represent XML data in full fidelity? If not, should it be extended?
	I'm not sure that the data is so much more complex than can be represented
by the DOM interfaces. Perhaps I have a different view than you do. The way
I see it, I can represent pretty much any piece of data using XML as I can
with say an s-expr. The issue is only one of efficiency (as it has been with
s-exprs). So, as I see it, if I put an efficient implementation behind an
interface, it might work in ways you haven't imagined.

> The XML data model, whether a grove or a DOM is the "Forrest
> Gump" of representations for your data. Sending a dumbed-down message by
> Forrest Gump is good: he will relate it faithfully. Installing him as the
> only conduit for information is bad. You'll have to dumb down too much
> information and spend too much energy re-assembling it on the other side.

	Really? And what is a more intelligent abstract data model? I'm not feeling
too limited yet but perhaps I'm doing simplistic stuff. SGML has been around
for years, but has never generated too much excitement. In contrast, XML.
Sometimes simple is very very good. Sometimes, the simpler things get the
more powerful they get.

>
> >         I wouldn't suggest that the DOM replace ODBC, yet I'm
> quite sure that those
> > experienced using a variety of systems with disparate data
> types and data
> > usages will appreciate that certain types of data are best
> expressed in tree
> > format. Such data scenario's might best be interfaced with via the DOM.
>
> You just need an API for "tree formats". Just ask your DBMS vendor to
> provide some tree-structured API. It doesn't matter if that API is the DOM
> because making it the DOM does *not buy you anything* as a programmer.
> From a programming point of view there is no benefit to working with a
> consistent API where everything is dumbed-down to a textual model. You
> might as well dumb everything down to an "object model." (see below)

	There exist dozens of proprietary database interfaces. Most people are
willing to accept a common denominator which is mostly acceptable because
the benefits gained by employing a widely accepted standard outweigh the
benefits of a locally optimized proprietary interface. On the other hand if
I want to create an optimized high performance system I already have lots of
options. Most of these do use object oriented programming, not that I can't
do it all in assembler, but rather because of the benefits of
maintainability and the reasonable performance of modern compilers. The
benefits of object oriented programming are orthogonal to object databases.

>
> If you buy this, then guess what the hype will be in three years: "These
> new fangled data bases have this really cool feature, dude. You call it
> with a SQL9X query and it can return like OBJECTS!. Everything in the
> world can be expressed as objects! Lists of objects. Lists of objects.
> Trees of objects. Directed graphs of objects. Arbitary graphs of objects.
> It like unifies everything as objects. It's Zen, man. They call it 'JDBC'
> and its totally wicked."

	What are you trying to say here?  Are you criticizing objects?
>
> The *only benefit* of unifying things as DOMs is reusing software that was
> originally supposed to work with XML (i.e. XSL implementations). If you
> are writing new software it makes NO SENSE to do it through a DOM
> interface unless your data source is *XML*.

	Suppose I want to process the data using XSL? Is this conceivably an
acceptable reason to use a DOM interface (assuming I don't actually want to
convert my database to serialized XML itself).

>
> Otherwise, you should just define a "tree node" interface and have your
> various objects implement it. You will get all of the the benefits of the
> DOM with none of the costs (i.e. how the hell do you represent complex
> properties of objects???). If you want some good hints about what a "tree
> node" interface looks like, take a look at the grove abstraction.
>

...
>
> Second, Even *XSL* is not best served by a DOM representation. James Clark
> wrote an xsl-list article about that but I can't find it now. Remember
> that the DOM was invented as an extension of "DHTML." It's only half
> "there."

	Certainly XSL is best served by a DOM representation if the data is
presented via a DOM interface. The other option is to serialize everything.
This makes no sense unless the DOM implemention is sub-optimal.

>
> But if I grant that some well-thought-through API for XSL trees could
> exist (i.e. Jade's grove API) then I would propose that it only be used as
> an optimization in a system where it would otherwise make sense to pass
> around serializations of text documents. i.e. the DOM is okay for skipping
> a layer of message passing. It is not okay as a "universal API" for "all
> of the data in an organization."

	I never said this. There is a difference between saying that something is
useful (i.e. placing a DOM interface on a database) and saying that this is
the only way things ought to be done.

>
> To bastardize JWZ: "Sometimes people have a hard data unification problem.
> One part of their organization speaks a very different language (at the
> data model and object model level) than another part. They might think 'I
> can unify these with XML or the DOM.' Now they have two problems."
>
> There second problem is that they didn't understand the really hard
> problem in their organization. Data model unification is *easy* (cast to
> java.lang.object or w3c.dom.node). Data model *rationalization* is very
> difficult. And I don't think that there are many shortcuts.
>
> >         Are the DOM interfaces the best for all situations,
> clearly not. However if
> > a significant percentage of people can agree to use them a significant
> > percentage of the time, this is a big win.
>
> That's not going to happen. The DOM will NOT be a core tool for that
> majority of OO programmers this year, next year, or ever. Programmers will
> try it and increasingly find that if they are not doing XSL styling for
> the Web or print that the DOM is not a core tool. "Old-fashioned" OO can
> provide the same benefits.

	What I am saying is that if these interfaces are accepted as a standard
mechanism for representing XML data, that this in and of itself is a big
win. XML is not close to replacing OO in fact it seems to be struggling with
OO concepts itself.

	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 the first XML programming
language and employs XML in a directly analagous way that LISP employs
s-exprs. If I feel that I can express any data structure in XML that I can
express as an s-expr, I see no good reason that, with proper extensions, XSL
would not be able to handle tasks that Scheme, or Lisp have been applied
toward. I believe XSL has a great future.

	If NN and IE contained native Lisp interpreters this might not be at all a
big deal, what I find interesting is that a high percentage of desktops
will, in the near future, gain the ability to run a data based
transformation language. Perhaps the first use is an engine to display XML
as HTML. I've developed a medical records system which employs XML and XSL
to do relatively simple processing on the client (and have used the DOM
interface for this BTW). As someone who has used many different programming
languages and systems, I have found surprised at what can be done with the
combination of XML, the DOM, XSL and JavaScript. The bottom line here is
easy of development and deployment. This is my initial experience. Use your
imagination.


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)