Lists Home |
Date Index |
Elliotte Harold wrote:
> Daniela Florescu wrote:
>> XQuery and XSLT do have a data model that will stay at the foundation of
>> XML processing in the future. I think it is too late by now to deny
> This is *a* data model. It is not *the* data model. There is no one
> XML data model, and there will not be. The XQuery/XPath 2.0 Data Model
> will only be the foundation for XQuery and XSLT 2. Many other
> developers will continue to profitably use other data models that
> better meet their needs. XML interoperability is based on exchanging
> syntax, not representations of data models.
I am not sure I understand your use of "data model".
Some DOM representation and a term notation a(b(c(),d())) surely have
the same data model (i.e. a tree)?
Surely a finger pointing to the moon is not the moon itself? (i.e. even
if you want to have object graphs, representing them as trees with
references does not hurt) ?
Even if we see some faithful "data binding" one day (something that maps
XML Schema to programming languages types, so that a typechecker can
check well-typedness statically), the object instances it gives you will
still allow you to recover the tree?
IMHO the only benefit that XML can possibly give to programming in general (and that's quite a great part of informatics & communication) goes through this model. And this is not even new! For instance, every decent Java compiler in the world represents the source as an abstract syntax tree - using objects fails miserably for modular compiler writing. For a reason.
But if your critique is about the *details* of the tree model, then we certainly agree. I think there will e.g. never be consensus about having a pointer to the parent in each node, because the data model one chooses for a programming language interferes with all (and I mean all) aspects of the programming language design.