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

[Paul Prescod <paul@prescod.net>]

Mark Birbeck wrote:
> 
> if that was a better model of the internal data. Maybe I've missed the
> subtlety of what you are saying the problem is, but in our system the
> attributes of an object are exported as described above, and the
> children of an object are exported as elements within other elements.
> Seems to me to mirror exactly our object structure - and so far we have
> been able to re-interpret DTDs back as data definitions. In other words,
> we *can* generalise the solution.

If I understand correctly:

 * what you are saying is that you can define (have defined!) a convention
such that you achieve lossless serialization of XML data through XML.

What Eliot is saying is:

 * XML isn't doing the "heavy lifting" here, your *convention* is doing
the heavy lifting. If someone handed you data that meant the same thing
but did not use your convention you would be as lost as if the data were
EBCDIC ISAM files.

XML is doing the "light lifting" of allowing you to avoid writing a parser
for EBCDIC ISAM files (or, more likely, LISP S-expressions). YEAH FOR XML!
Helping with light lifting is important. Saving money is important. It
just doesn't solve the hard problems. Non-ambiguous serialization has not
been a hard problem since the invention of S-expressions.

> Sure. But I still have two issues. First, why would you query the
> serialisation anyway? Wouldn't you want to query your original database
> and generate XML pages that reflect the results? 

You certainly would if you use XML as *only* a serialization. The thrust
of this thread was that some people want to encode everything in XML so
that they can "query it." But XML is a lousy query representation for
anything other than human-authored documents. (and debatably the best
thing for queries against those!)

> You keep talking of the 'abstract' representation
> of your data, but actually you are *losing* the abstraction, moving
> from:
> 
>         a person who has the name Eliot
> 
> to
> 
>         an object which contains another object which has two
> properties, one set to name and the other set to Eliot
> 
> Of course both are abstractions, but they model completely different
> things (data and people). 

I think that this is Eliot's point. Consider someone who says that if you
put a "DOM interface" on all objects everywhere in the system then they
all become managable because they have a "single API." Smart (but usually
inexperienced) people say this. These people are talking about an API to
the serialization structure instead of an API to their original data.
They've gained some uniformity but lost some abstraction. That is very
seldom a useful trade-off. To make their processing useful again their
very next step will be to add in some abstraction on top of the DOM. Then
they're back to where they started.

This is one of the most pervasive misunderstandings in XML-world.

> And modelling the data rather than the person
> means you can no longer interchange your XML with other systems because
> you have two completely different sets of data, using different DTDs.

I don't follow that.

> (And you can't say that your serialisation schema *will* allow this
> interchange, because although your serialised data may be well-formed,
> the underlying data it represents may not be, so you need the proper DTD
> for the object.)

Well-formedness has very little to do with DTDs so I don't follow this
either.

> All I am saying is that the document *itself* could be the abstraction
> of the data.

This is something else I don't follow. XML documents are always encodings
of abstractions. They are concrete, tangible, interchangable, printable
and can be given global names. Concrete, not abstract.

The objects they represent are logical, usually inaccessible outside of an
"address space" (i.e. your brain, your relational database) and are thus
termed abstract. The reason we need XSL is because the abstractions cannot
"stand alone". I can't transmit a book from my head to your head. I need
to serialize it on paper or online. I also can't transmit a "book object"
without serializing it somehow (i.e. XML). Before serialization it is an
abstraction.

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