RE: i042: Extensibility Model

+1 to Jonathan's proposal.  I think that an extensibility section is an
excellent idea and may set a template for future specifications.  

I likewise agree that WS-A should not provide a "mustUnderstand" model,
as this seems unnecessary when SOAP will often be used for WS-A
properties.  Further, this would introduce redundant and unnecessary
complexity (such as how to deal with multiple mU extensions) in a soap
stack - 1 at the soap layer and 1 at the ws-a layer. 

I further agree that a "must ignore unknown" is an appropriate
substitution rule for software that does not understand the extension.

I would like to propose that an introduced ext/vers section provide 2
simple examples: a forwards compatible and a forwards incompatible
extension.  These would show how extension authors can/should use the
soap processing model.  I propose this for the e/v section because I'm
hoping that we won't need to make a primer, which would be a logical
alternative for this kind of information.

Cheers,
Dave

> -----Original Message-----
> From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-
> request@w3.org] On Behalf Of Jonathan Marsh
> Sent: Friday, February 04, 2005 1:21 PM
> To: public-ws-addressing@w3.org
> Subject: i042: Extensibility Model
> 
> 
> >From [1]:
>   "We discuss the fact that extra elements/attributes might appear in
>   the infoset of an EPR in section 2.2, but we do not discuss any
>   sort of a processing model for these extensions.
> 
>   "Also, The abstract properties list in section 2.1 doesn't have
>   any statement about extensibility.
> 
>   "Also, We should decide if we want to support a 'mustUnderstand'
>   marker on extensions a la SOAP/WSDL, or if we want to discuss
>   'ignoreUnknown' semantics for unrecognized extensions/properties."
> 
> Taking mustUnderstand first: EPRs are intended to be exchanged in some
> context.  It seems to me that there is sufficient mechanism within
that
> context, outside the EPR itself, to communicate the
> mustUnderstand-edness of the extension.  For instance, if I transmit
an
> extended EPR as a SOAP header, I can leverage soap:mustUnderstand.  If
> my EPR is intended for use by a client who has a WSDL I've provided, I
> may use a required feature or wsdl:required to indicate that the
client
> must be able to process EPR extensions.  If I transmit the EPR through
> some other mechanism, that mU facilities of that mechanism could be
> used.
> 
> Sans fancy wording, I propose that we:
> 
> 1) Clarify that the processing of extensions is defined by the
>    specification for that extension.
> 
> 2) Clarify that unknown extensions may be safely ignored for
>    the purposes of processing WS-Addressing properties.  (A
>    mustUnderstand marker seems like overkill to me.)
> 
> 3) Clarify that extensions are allowed to modify the values of
>    the existing Endpoint Reference Properties.  Note that this,
>    combined with the ignore-unknown rule (2), may result in a
>    difference of behavior between a processor that understands
>    such an extension and one that does not.  Extension
>    developers should consider whether they desire this
>    "fallback to vanilla WS-A" behavior when designing such
>    an extension.
> 
> 4) Clarify that extensions are allowed to modify the rules for
>    binding the endpoint reference properties to a particular
>    transport (such as SOAP).  Or to phrase another way, to
>    indicate that a different binding to the transport should
>    be used.  Same caveat applies here as to (3).
> 
> 5) Clarify that extensions may introduce new properties.
> 
> These clarifications might best be captured in a subsection on
> Extensibility rather than trying to distribute them throughout section
2
> as the issue text implies.
> 
>  [1] http://www.w3.org/2002/ws/addr/wd-issues/#i042
> 
>

Received on Friday, 18 February 2005 20:15:49 UTC