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, 4 February 2005 21:21:19 UTC