RE: New LC Issue: Changes to wsaw:Anonymous

Yes, I think that is syntactically equivalent to an explicit
"unspecified" value.

> -----Original Message-----
> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
> Sent: Friday, April 07, 2006 12:31 PM
> To: Jonathan Marsh
> Cc: public-ws-addressing@w3.org
> Subject: Re: New LC Issue: Changes to wsaw:Anonymous
> 
> Jonathan,
> 
>  > Because there is no way to say, "I'm using addressing, but making
no
>  > design-time claims /here/ as to support for anonymous addresses",
>  > wsaw:UsingAddressing is unsuitable as a universal mechanism for
>  > engaging addressing.
> 
> Is this an issue with the default value of wsaw:Anonymous being
> 'optional'. I.e. does the concern go away if we say that there is no
> default value (i.e. unknown)?
> 
> -Anish
> --
> 
> Jonathan Marsh wrote:
> > Section 3.2: Anonymous Element.
> >
> >
> >
> > wsaw:Anonymous does not correspond well with the features of WCF.
> > Instead of providing a single SOAP binding that can be parameterized
at
> > will to accept anonymous URIs, our implementation provides separate
SOAP
> > bindings for anonymous and non-anonymous cases.  This makes direct
> > support for the "optional" value impractical for us to support
during
> > the CR testing phase.  For this reason we'd like to see
wsaw:Anonymous
> > functionality deferred so it doesn't hold up the rest of the
> > specification.  However, the current design also places undesirable
> > limits on the evolution of anonymous handling in the future.
> >
> >
> >
> > In general we are currently tending towards favoring sets of
composable
> > assertions rather than a monolithic, though parameterized, assertion
or
> > extension.  In WS-Policy generally, multiple assertions with
distinct
> > QNames are preferably to a single assertion that uses attributes
and/or
> > content to distinguish different cases. For example, given two
possible
> > assertion designs;
> >
> >
> >
> > 1.         <A1/>
> >
> > <A2/>
> >
> > <A3/>
> >
> >
> >
> > 2.         <A Parameter='1' />
> >
> > <A Parameter='2' />
> >
> > <A Parameter='3' />
> >
> >
> >
> > then design 1 would generally be preferred because it allows the
policy
> > matching logic to provide more accurate matches between policies.
> > Anonymous handling currently feels more like design 2.
> >
> >
> >
> > This results in a suboptimal expression of anonymous handling when
> > UsingAddressing appears as a policy assertion.  The lack of a
> > "ws-addressing engaged" primitive assertion prevents UsingAddressing
> > (used as a policy expression, a WSDL extension, or through the soap
> > module synonym) from composing well with other primitive (or
composite)
> > extensions or assertions that govern the handling of anonymous.
> >
> >
> >
> > For instance, we plan to develop and deploy policy assertions which
> > represent composite functionality, one aspect of which may be
> > constraints upon anonymous handling.  As far as WS-Addressing is
> > concerned, this represents out-of-band specification of
> > wsaw:Anonymous-like capability.  Unfortunately, the value space of
> > wsaw:Anonymous is not extensible, and forces one to make claims as
to
> > the treatment of anonymous addresses.  Other assertions may
contradict
> > the claims made in wsaw:Anonymous, impeding consistent and accurate
> > description and therefore interoperability.  Another bad effect of
only
> > providing a composite design is that anonymous address handling
cannot
> > be separately negotiated at runtime through trial and fault.
> >
> >
> >
> > Because there is no way to say, "I'm using addressing, but making no
> > design-time claims /here/ as to support for anonymous addresses",
> > wsaw:UsingAddressing is unsuitable as a universal mechanism for
engaging
> > addressing.  Rather than a composite assertion covering both
engagement
> > of WS-Addressing and anonymous handling, we'd prefer to have
composable
> > primitives representing this orthogonal functionality.
> >
> >
> >
> > We also note that some members of the WG have stated their desire to
use
> > wsaw:Anonymous as a hint for code generation (sync, async).  We
don't
> > think overloading anonymous is a good way to hint as to how a
> > programming model should be built, and would not support the
retention
> > of wsaw:Anonymous solely for this purpose.
> >
> >
> >
> > We therefore propose that wsaw:Anonymous be removed from this spec
and
> > features to constrain anonymous or hint at programming models be
> > deferred to future specs.
> >
> >
> >
> > Failing that, we ask that "unspecified" be added as a value for
> > wsaw:Anonymous, and that this value be treated as the default when
no
> > wsaw:Anonymous element appears.  The addition of an "unspecified"
value
> > enables the wsaw:UsingAddressing extension/assertion to act dually
as a
> > primitive and composite assertion, and compose with other mechanisms
of
> > indicating the handling of asynchronous messages as they are
developed.
> >
> >
> >
> > ** [  **Jonathan Marsh ** ][ ** jmarsh@microsoft.com
> > <mailto:jmarsh@microsoft.com> ** ][
> > ** http://spaces.msn.com/auburnmarshes**  ]**
> >
> >
> >

Received on Monday, 10 April 2006 16:09:33 UTC