OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: Re: [xml-dev] Transactional Integrity of Services (LONG)

[ Lists Home | Date Index | Thread Index ]

On Sun, 30 Mar 2003 07:03:56 -0700 (MST), Linda Grimaldi 
<grimlinda@earthlink.net> 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@w3.org 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.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS