Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Re: Transactional Integrity of Services (LONG)
 On Sun, 30 Mar 2003 07:03:56 -0700 (MST), Linda Grimaldi <grimlinda@e...> wrote: > Many of the questions about XML seemed to stem from a confusion over XML > as a data representation and XML as a protocol. It seems to be used at > different times as both-and sometimes at the same time as both. It got > particularly confusing for people at a web services session-the payload > is XML, the protocol (SOAP) is XML, etc. Does XML contribute to the > blurring of the distinction between data and protocol, and, if so, is it > a good thing or a bad thing? IMHO, XML epitomizes the old joke ... "It's a floor wax ... it's a dessert topping!" It's not particularly good at much of anything (not even document markup, at least compared with full SGML), but it's "good enough for guv'mint work" for all sorts of things. What it lacks in fitness for a particular task is often more than made up by the network effect created by its ubiquity. So, I agree that XML contributes to the blurring of the distinction between data and protocol. This has its downsides (witness the REST permathread on the w3c web services mailing lists) but again IMHO the benefits of ubiquity overwhelm them. For example, the "visibility" permathread on www-ws- arch@w... earlier this year convinced *me* (but not the RESTifarians) that XML's ability to blur the distinctions among application protocols, transport protocols, and data makes XML-based messages very leverageable by a whole raft of intermediaries such as routers, firewalls, encryption devices, etc. If one does not blur the distinction between data and protocol, then intermediaries can only exploit data that is visible to the protocol (e.g., the HTTP headers). This is fine in a pure, designed for all-one-protocol environment, but creates all sorts of problems when bridging conceptually different protocols. Putting information in the fuzzy intermediate XML zone (such as SOAP headers) allows those ubiquitous XML processors to look deep inside the message (with XPath, SAX, DOM, regexp, whatever) to make routing/filtering decisions that would be impractical before XML came along. 
|
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
|
|||||||||
