Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Typing and paranoia
 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
