Lists Home |
Date Index |
Michael Champion wrote:
> OK, maybe you could back up those assertions: Why won't there be a
> single "XML" data model at some point? I suspect one will emerge
> simply because the insanity of end users having to switch back and
> forth from a DOM-ish view to an XPath-ish view of namespaces and
> syntax sugar is unsustainable.
There is no single data model now, and it's quite obvious that none of
the proposed single data models will meet all needs. For instance, many
people have expressed a positive desire to continue working with XPath
1.0 and XSLT 1.0, and ignore XQuery and XSLT 2. That's fine. They can
use the data model that suits them. In my own work, I routinely shift
data models, depending on what I'm doing. Sometimes I use an event
model. Sometimes I use any of several tree models. Sometimes I use plain
text. One data model does not fit all my needs, much less the needs of
the millions of developers out there.
> And what is the *evidence* that "XML interoperability is based on
> exchanging syntax"? As I see it, lots of DOM scripts work in multiple
> browsers, *all* XQuery-based integrations work off a representation of
> a data model that is independent of syntax, many "binary XML" formats
> are essentially serializations of the SAX event stream yet
> higher-level tools don't care ....
DOM in browsers is interoperable! Wow, that's a surprise. It's certainly
not been my experience. But even granting that, it's one small part of
the things people do with XML. It's no shock to say that all XQuery
implementations support the XQuery data model, but that's still just one
language and one data model. There are other languages and other data
models. Indeed in this very paragraph you've mentioned three different,
incompatible data models as examples of interoperability. each
interoperates only within its own domain. For instance, it's recently
become apparent to me that the DOM data model is missing pieces that the
XInclude data model depends on and which SAX does provide.
> Nobody disputes that having a canonical bits on the wire format for
> XML is a Good Thing and is the interop definition of last resort. The
> disagreement is over whether that raw syntax is an appropriate
> representation for real-world programmers to work with directly. If
> anything, I'd argue that only a small subset of XML consumers (as
> opposed to authors) deal with it at the bits on the wire level, and
> many of them (such as RSS aggregator developers?) treat it as XML-ish
> tagged text rather than well-formed XML.
You're confusing layers here. Of course, everyone will use some data
model to process their XML. However, everyone will not use the same data
model. Each will choose the data model that meets their needs. Sometimes
this data model won't look anything like XML. Often, they'll have
several different layers of data models. Claiming that everybody must
use the same data model to process XML in order to achieve
interoperability is just as silly as claiming everyone must use the same
programming language. Data models are a local choice, not a global one.
Elliotte Rusty Harold email@example.com
XML in a Nutshell 3rd Edition Just Published!