RE: i042: Extensibility Model

>-----Original Message-----
>From: public-ws-addressing-request@w3.org 
>[mailto:public-ws-addressing-request@w3.org] 
>Sent: Friday, Feb 04, 2005 13: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.

Hi Jonathan, 

I would like to understand couple of the suggestions you are making
below. 

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

I have a clarification question about point 3. I am not clear how
allowing extensibility to modify existing properties may mean,
specifically with regards the roles, EPR minter and the recipient of the
EPR. I am wondering who is allowed to modify the EPR's exising
parameters in processing the extension and how this would affect the
interaction using the modified EPR. 

Modifying the properties of an EPR is only interesting from the
perspective of the EPR recipient. Otherwise, I claim that it is not that
interesting for the EPR minter. I am particularly curious about the
[reference parameters] property. I will describe a scenerio where this
is possible with (5) and (3). 

Lets assume that there is an extension property (5) in the EPR. This
extension (say [add-new]) has the semantics of the to add a new
parameter to the existing params, hence modifying the [reference params]
property, which is (3).  

The EPR minter sends an EPR which contains a new extension property
[add-new] per 5.  

The receiver gets the EPR, processes the extension. Its semantics is  to
add a new parameter to the existing refParams. It adds a new parameter
and value. 

The receiver then sends a message using the modified EPR, using the SOAP
binding. The parameters now contain not only the opaque data (from the
perspective of the recipient), but also stuff that the EPR recipient
wanted to send to the endpoint. 

I presume this scenerio is allowed with the extension proposal. Let me
know whether I got this right. 


--umit

Received on Friday, 11 February 2005 03:57:16 UTC