[
Lists Home |
Date Index |
Thread Index
]
Mike Champion wrote:
> Well, with all respect, that's just not the reality I live much of my
> life in. Web services are often implemented with synthetic infosets that
> are only
> serialized as XML at the very end of the road.
At the very end of the road, then, they're XML. When they're sloshing
around inside the Web Services machinery they're handy useful data
structures that nobody should confuse with XML.
> As
> Martin Gudgin says in the piece that Len quoted (disapprovingly?)
> http://msdn.microsoft.com/webservices/understanding/default.aspx?pull=/library/en-
> us/dnxml/html/xmlinfoset.asp
> "If a DOM tree sprouts, grows, withers and dies and is never serialized
> using angle brackets" ... it *is* XML IMHO. There is more (or less) to t
> he XML brand than the angle brackets, or else DOM, SOAP, XPath, and
> XQuery (ahem, the W3C specs I have the most personal interest or
> involvement with!) are not about "XML". There's an
> awful lot of "XML" interoperability at the level of SAX events, DOM
> trees, XPath or
> XQuery queries, SOAP messages, etc.
I disagree with so much of this paragraph that I'm going to have to
number 'em:
1. A DOM tree is not XML. It's related to XML, but if you pass me some
instance of a DOM tree, it's not XML unless it's unicode characters with
angle brackets. I have the specifications on my side on this one and
I'm not backing down. I'm not denying that someone might want to pass
DOM trees around, I'm just saying that this gives up most of the
interoperability advantages of XML and shouldn't be billed as
interchanging XML.
2. Indeed the XML brand grows worryingly, but it is terribly important
for the integrity of that brand that when someone says "this data is
available as XML", that they provide unicode characters with angle
brackets on demand.
3. I have yet to encounter, in 21 years in the software business, any
program-level facility, whether it be SAX events, DOM trees, SQL APIs,
POSIX, you name it, that offers the interoperability you get by
exchanging XML messages. If your SOAP messages are unicode characters
with angle brackets, they're likely very interoperable. If not, not.
The only documented way to interchange any of these constructs at the
moment is streams of text with embedded markup, and this is as it should
be. What you do in the privacy of your sandbox is entirely up to you,
but don't pretend that it's XML and don't pretend that it's
interoperable. The only really interoperable APIs are those that are
defined by a single implementation, e.g. Win32 and Apache APR and so on.
XML exists to get us out from under that rock.
There's a deep tension here that won't go away. Some of us really
REALLY want to be able to deal with the bits on the wire and REALLY like
the open-ness and interoperability that gives us. Others really REALLY
want to take the bits on the wire away and present us instead with an
API that has 117 entry points averaging 5 arguments and try to convince
us that this is somehow equivalent. XML, for the first time in my
professional career, represents a consensus on interoperability: that it
is achieved by interchanging streams of characters with embedded markup.
Since about 15 seconds after XML's release, the API bigots have been
trying to recover from this terrible mistake and pretend that the syntax
is ephemeral and the reality is the data structure, just read chapters 3
through 27 of the API spec, buy the programmer's toolkit, sign up for
professional services and hey-presto, you'll be able to access your own
data, isn't that wonderful!?!?
But you're not going to take the bits on the wire away from us without a
huge messy noisy fight down to the last ditch. -Tim
|
