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

Below:

> -----Original Message-----
> From: Glen Daniels [mailto:gdaniels@sonicsoftware.com]
> Sent: Sunday, February 27, 2005 4:23 AM
> To: Jonathan Marsh; Mark Nottingham; Hugo Haas
> Cc: public-ws-addressing@w3.org
> Subject: 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?

The spec has a dated URI.  To be completely clear about semantics of the
property, whether it has a URI or not, you need to reference that dated
version of the spec anyway.

> How do I make an assertion in RDF about "the WS-Addressing
> [destination] property"?

Why is this our problem?

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

Property URIs don't help with this problem in our case because many of
the specs we need to compose with don't have property URIs.  How would
the addition of URIs help a system that supports both the WS-A Rec (when
it's done), and the WS-A submission?

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

That sounds harmless enough, but experience has shown that property URIs
don't stop there but keep popping up in the syntax.  I think you've
substituted RDF above for WSDL in hopes that some people won't care as
much.

> 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?

I reject that choice.  You can get unambiguous references to concepts in
our spec by referencing the spec.

> > > >   - 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 13:45:02 UTC