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

[Paul Prescod <paul@prescod.net>]

"Borden, Jonathan" wrote:
> 
> > You are interacting with data through an interface that was designed to
> > provide access to the abstract data model of a *serialization*. 

>         Really !? and I thought I was interacting with an interface designed to
> represent the abstract data model of XML. 

Right. XML is a serialization. The DOM is an abstraction of a
serialization. Not an abstraction over your data. 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."

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

No. It isn't meant to.

> If not, should it be extended?

No. It isn't meant to.

>         I'm not sure that the data is so much more complex than can be represented
> by the DOM interfaces. 

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. We have
20 years of software engineering that DOES help us to manage that
complexity and its most recurring message is "abstraction, abstraction,
abstraction." Dumbing data down to a DOM is the opposite.

"If we make the trees large enough then a forest and an orchard will look
the same." Too bad you still can't see the forest for the trees.

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

I've never claimed otherwise. The question is whether XML presents a good
*API* to that data.

>         Really? And what is a more intelligent abstract data model? 

Object orientation.

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

No. I am saying that the only "API" that can unify all of the complexity
of all of the data in an enterprise is "object orientation" or perhaps
something even more powerful. Dumbing everything down into elements and
attributes is not a step forward, but a step backward. The DOM itself is
evidence of this. Note that the DOM's creators did not make a CSS DOM by
representing CSS in terms of elements and attributes. They made a whole
new set of methods and properties. They used *object orientation* not XML.
The CSS DOM has absolutely nothing to do with XML *as it should not*.

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

No. The other option is to make an API that takes into account the needs
of XSL implementation.

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

The DOM is pretty good at representing XML data. If that is all you want
to say, fine. The point of this thread is that there are people who think
that the DOM is great at representing data of all sorts. You should just
throw a DOM interface over your database and all of your interoperability
problems will go away.

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

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