[
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.
|
