[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Re: Transactional Integrity of Services (LONG)


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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.