[
Lists Home |
Date Index |
Thread Index
]
5/21/2002 4:36:41 PM, Tim Bray <tbray@textuality.com> wrote:
>Does that mean I can publish a huge gnarly proprietary API which among
>other things provides manipulation of the Infoset, and hide some product
>or service behind it, and insist that you use my DLL to access this, and
>at the same time claim to be SOAP-compliant?
You might be compliant with SOAP per se, but unless you comply with an
agreed-upon protocol binding, you couldn't actually interoperate
with anyone. "SOAP Processors" work on the InfoSet, so one could
presumably layer various parsers that translate a concrete syntax
into the InfoSet on top of a single SOAP processor.
I personally think this is a Good Thing ... if SOAP
were still defined in terms of pointy brackets, it would have to be
redefined at the syntax level to allow something like the GET binding
URI magic. As it stands, one just has to define how the InfoSet (that
subset of it that SOAP understands anyway) is mapped onto URI syntax,
and the semantics of SOAP per se stay as they are. If this all works
out, those who want to access a service by POSTing a payload with
a lot of angle brackets, and those who want to access a service by
GETing a long URI, can more or less peacefully co-exist.
Of course, the downside is that some hypothetical alliance of convicted
monopolists (ahem) might be tempted to embrace the XML Infoset, then
extend away the pointy bracket syntax in favor of something that better
suits their business needs, all in the name of efficiency, security, or
whatever. That's certainly something the rest of us need to watch out for.
[As usual, this is my best understanding of a complex and fluid situation,
and will gladly stand corrected if my understanding is wrong]
|
