RE: i051: Binding of message addressing properties in the SOAP underlying protocol [i051]

Hi Jonathan:

> I see no interop benefits from defining SOAP features and 
> properties.  I
> see no benefits in writing other specs.
> 
> Which is easier to read:
>   "http://www.w3.org/YYYY/MM/addressing/soap12/feature/Destination"
> or
>   the WS-Addressing [destination] property?

Which version of the WS-Addressing [destination] property was that
again?  How do I make an assertion in RDF about "the WS-Addressing
[destination] property"?

> It just complicates the spec and makes it and dependent specs 
> less human
> readable.  We've been successfully using the latter model for infoset
> references in specs for some time and it seems to work very well.

I think the entire composability story for WS-* specs in general remains
in doubt until we have real systems using multiple versions of multiple
specs, so I'm not sure I buy your last sentence here.  SOAP F&P was
designed to be a (relatively) lightweight way to unambiguously represent
things precisely like our abstract properties, in order to a) be crisp
and clear about meaning, and b) enable technologies like RDF to easily
(and interoperably) express knowledge/assertions/rules about such
things.  Is it more important that some SOAP implementer (and already I
think we're talking about a fairly small and hardcore community) be
coddled with a spec that's more free of URIs, or more important that we
do our best to enable unambiguous references to concepts being developed
in potentially disparate groups?

> > >   - the SOAP header doesn't need to be serialized in the 
> envelope as
> > >     it's expressed at the underlying binding level.
> 
> This complicates life immensely for end-to-end scenarios and is a much
> bigger issue than whether or not we define some (worthless 
> IMO) property
> URIs.

I understand the argument here, and to some extent sympathize with it -
I just feel the need to mention that the argument from the other side is
that SOAP was built to take advantage (or at least enable taking
advantage) of the underlying semantics of whatever protocol it runs
over.  If we decided that <To> could be optional when it's carried by
the underlying protocol....

--Glen

Received on Sunday, 27 February 2005 12:22:56 UTC