RE: Data storage, data exchange, data manipulation

[Jonathan Borden <jborden@mediaone.net>]

Nicolas LEHUEN wrote:

>
> I don't think a node-labeled tree (the XML model is a tree, more
> restricted than a graph) structure can model all kind of data
> easily and efficiently.

There is a wealth of discussion on representing graphs in XML. Techniques
include ID/IDREF, XLink/XPointer, RDF, TM etc, etc. The easy and efficient
part depends on the implementation.

>
> So I believe there is a whole set of problems that will benefit
> from XML databases (which are I believe based on the hierarchical
> database model*, maybe Mike can confirm/infirm). The storage,
> indexation and querying of a set of document-oriented data is a
> good example.

Similarly there is a lot of work on XML 'enabling' of relational databases.

>
> But XML databases isn't or (won't) be a revolution, blasting all
> other storage models. We could even say that the XML database
> model is just a come back of the hierarchical model that was
> supposedly "killed" by the relational model back in the 80s. I
> don't think XML databases are the "next thing".

If we forget hype and terminology, there *is* real work being done on the
XML Query Model and XML Query languages. One needs to distinguish between a
query model and an internal representation.

> ...AFAIK, the only ways a computer
> can exchange data with a human being are serial, and I feel that
> hierarchised text or speeches are the highest form of structured,
> serialized data that we can understand.

actually humans are not limited to serial data formats, e.g. images and
voice which is interpreted by humans in a nonlinear, non serial fashion.
>
> C] In-memory data storage and manipulation using XML
>
> This last point on presentation is very important to me, as its
> consequences finally made me to abandon any attempt of modeling
> data as full-featured objects in the development of presentation
> layers

The work on types in schema languages would suggest otherwise. The DOM (L2)
is limited to a small number of fixed types "element" "attribute" "text"
.... When type support becomes a part of DOM Level ?.? the DOM does become a
general 'object' model. It is not at all clear to me that representing
everything in a DOM _saves_ memory.

>
> To save development time, deployment time, and memory (all thoses
> classes modeling data come at a high price), we chose not to
> model data as full-featured object, but simply as XML DOM
> Documents. ...
>
> - it saves a lot of memory by removing application-specific
> classes and replacing it with a small set of classes, the DOM.

The statement that use of the DOM saves memory is against many common
beliefs. (Indeed I try to use SAX as much as possible to avoid the DOM
memory overhead.) Can you support these claims with some data?

>
> - it saves a lot of time and energy by the sheer flexibility of
> XML.

This is where XML wins hands down in my book.

>
> - contrary to Java class definitions, XML schemas (or schemata if
> you prefer :) are quite difficult to read and write.

And people will complain that XSLT is more difficult to read and write than
Java, so?

>
> - compile-time checks are not performed. If you call
> person.setFavoriteColour() on a Person instance, and the Person
> class has not this method, you will get a compile-time error.
> Using Java + DOM, a compiler cannot see an error when you try to
> add the "favoriteColour" attribute or child element to a "person"
> element. As we have developed a custom XML language compiled to
> Java code, we feel that it is possible to make the compiler
> schema aware, thus enabling compile-time checks when the schema
> of the manipulated documents are known.

correct on all accounts. in this sense these usages of XML have the same
issues as all dynamically typed and/or interpreted systems ... and the same
solutions :-)

>
> - "this is not pure object oriented programming !" I don't know
> if it is the same out there, but here in France it matters to a
> lot of people.

that's too bad :-/

My current 5 seconds answer is that presentation
> layers usually do not require a pure object oriented model for
> data. It does not mean that the underlying framework of the layer
> is not object-oriented, far from it !

i'd just say "but of course we use Java so it *is* object oriented"!

>
> - "yeah, but then how do I associate a behaviour to my data ?"

In Texas you'd pull out a shotgun and blast at the general direction of the
individual. In Boston we mumble some phrases about the "Semantic Web" ...
"RDDL" ... wave our hands and then walk away :-)

winmail.dat