Re: abstract XML and bytes-on-the-wire interoperability

I'm not exactly sure what Dan C's post was suggesting, but I'd make a
couple of observations.  First, the question of whether "XML" is really
and truly a bits on the wire format, or an abstract information model
that has a standard bits on the wire serialization, is an ur-Permathread
on xml-dev.  I doubt very much if you could get real consensus across
the XML community on any particular resolution.  Keep in mind that not
only Schema, but XPath1/XSLT1, XPath2/XSLT2/XQuery, and all flavors of
DOM build on an abstract information model  rather than a concrete
syntax.  Be wary of making assertions about theoretical problems this
might create without considering the actual successes these specs have
had (although admittedly "interoperability" is not their strong suit). 

 

Second, it's important to distinguish "interoperability" from related
concepts such as interchange, portability, consistency, learnability,
etc. It is clear that effective data interchange depends on a shared
understanding of the bits on the wire format. That's XML's core value
proposition, and very few of us would want to threaten it.
Nevertheless, the other properties don't necessarily depend on a bits on
the wire format.  The most obvious example is HTML (and to a lesser
extent CSS and DOM)  - by all sorts of heuristics and hacks, the various
web browsers do a pretty good job of consistently displaying text and
even manipulating content with AJAX techniques even though conformance
to the (X)HTML specs about the bits on the wire format is the exception
rather than the rule. 

 

The harder question is portability, e.g. of DOM or XQuery code across
processors.  Ideally the W3C would be able to guarantee that any correct
DOM script or XQuery expression would produce the same results across
all conformant implementations.  In reality, given the experience with
DOM and especially SQL over the years, this is unrealistic - vendors
will add extensions to meet their specific customer needs,
implementations will interpret the semantics of the specs differently,
some features of the spec may not be practically implementable in a
particular product, etc.  It would be more practical to anticipate
portability of XPath/XSLT/XQuery/DOM code (as opposed to
interoperability data) at about the level that SQL achieves - it is
relatively easy to learn one flavor of SQL knowing another, it is
generally practical to port an implementation from one platform to
another, but it is not reasonable to expect implementations to
completely and exclusively conform to any particular version of the SQL
standard, nor for programs written for one implementation to work
unmodified on another.  Perhaps we can do better in the XML world, but
focusing on bits-on-the-wire is only a tiny part of the solution.

 

So, XML per se is all about a bits on the wire format for data
interchange (or "data interoperability" if you prefer), and anything
that threatens that value proposition creates significant problems that
the TAG should work hard to address.  With many of the other specs,
however, "interoperability" is less achievable in practice, and bits on
the wire issues are the least of the reasons why (e.g., the schema
interoperability problems that the June workshop will address).
Finally, it's important to be clear on what "interoperability" means in
a specific context and to set realistic expectations for what degree of
interchange, portability, etc. can be expected.

 

If this is obvious, or unrelated to the point Dan was making, I
apologize for wasting your time.