RE: Issue 6587 (Notational Conventions Text) - Proposal

Katy,
We believe "mustUnderstand" only works for the SOAP header block, not for the Eventing elements in the body.
See http://www.w3.org/TR/soap12-part1/#soapmu
"A SOAP sender generating a SOAP message SHOULD use the mustUnderstand attribute information item only on SOAP header blocks. A SOAP receiver MUST ignore this attribute information item if it appears on descendants of a SOAP header block or on a SOAP body child element information item (or its descendents)."

Here we are specifically talking about extension elements within the Eventing elements themselves and so using "mustUnderstand" will not work.

Thanks,
Geoff



From: Katy Warr [mailto:katy_warr@uk.ibm.com]
Sent: Tuesday, March 03, 2009 2:54 AM
To: Geoff Bullen
Cc: public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org
Subject: RE: Issue 6587 (Notational Conventions Text) - Proposal


Geoff,

Thanks for your response.  Yes, I can see now why it's important for WS-E to fail on processing unknown extensions.

I prefer the consistent option (2) because readers/implementers are likely to make the assumption that the Notational Conventions sections in each of the WS-RA specs is identical.    In a way, having these sections very nearly the same (but not quite) could potentially cause more confusion.

As an alternative to 2 could we consider exploiting soap mustUnderstand? This would provide a simple solution which could apply across all extension points (and therefore not require exception text scattered through the spec).   For example, this would enable the event source to indicate that a filter dialect must be understood by the recipient and can't simply be ignored.

Here's a proposal for this:

3) Replace the following in the Notational Conventions section for all 5 specs:

 ... By default, if a receiver does not recognize an extension, the receiver SHOULD ignore the extension; exceptions to this processing rule, if any, are clearly indicated below.

with

  ... By default, if a receiver does not recognize an extension, the receiver SHOULD ignore the extension; exceptions to this processing rule, if any, are clearly indicated below.  In accordance with SOAP processing rules, the SOAP mustUnderstand attribute SHOULD be used to indicate that the processing of an extension is mandatory.  If a receiver does not recognize an extension tagged with a SOAP mustUnderstand, it MUST fail processing the message and report a fault.

Thanks,
Katy

From:

Geoff Bullen <Geoff.Bullen@microsoft.com>

To:

Katy Warr/UK/IBM@IBMGB

Cc:

"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>

Date:

03/03/2009 04:10

Subject:

RE: Issue 6587 (Notational Conventions Text) - Proposal




________________________________



Katy,
Issues 1, 2 and 4 do appear editorial and are fine.
We believe there are reasons why Eventing is different from other specs - Eventing sets up a contract between the two parties - source and sink - and both these sides need to understand exactly what that contract is and how it works.  Having either side "ignore" possibly important requirements will not work in this situation.
Thus there seems to be two possible solutions to issue 3:
1)      Leave the Eventing definition different from the other 4.  We agree that the other four should move towards the RT/MEX wording version.
2)      Allow the Eventing definition to use the same words as the other 4, and also add words for every extension point in the Eventing spec saying that if the event source does not recognize the extension, then the message must fail.  This is similar to the text already used in many places in Eventing, for example in the filter section:
"If the event source supports filtering but cannot honor the requested filtering, the request MUST fail, and the event source MAY generate a wse:FilteringRequestedUnavailable fault indicating that the requested filter dialect is not supported."
Both options lead to the same result.  Option 1 means less work, option 2 provides greater consistency.
We don't really mind which of the above options is chosen.
Cheers,
Geoff

From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Katy Warr
Sent: Thursday, February 26, 2009 7:50 AM
To: public-ws-resource-access@w3.org
Subject: Issue 6587 (Notational Conventions Text) - Proposal


Here is a proposed solution for http://www.w3.org/Bugs/Public/show_bug.cgi?id=6587.
Points {1}..{4} are labelled on the sample Notational Conventions text that follows the text explanation of these points below.  Points {1}, {2} and {4} look like they are editorial only whereas point {3} is worth some attention as there is semantic difference between the specs.
thanks
Katy

{1} Extremely minor editorial change to WS-Mex to ensure consistency [RFC2119] -> RCF 2119 [RFC2119]

{2} Brackets mean different things across the specs:
EVENT/ENUM >>
The characters "[" and "]" are used to indicate that contained items are to be treated as a group with respect to cardinality or choice.
TRAN/MEX/RT>>
The characters "(" and ")" are used to indicate that contained items are to be treated as a group with respect to cardinality or choice.
The characters "[" and "]" are used to call out references and property names.
I recommend that we pick up the TRAN/MEX/RT text and ensure that the [] brackets are changed to () in EVENT/ENUM

{3} Ellipsis definition differs across the specs - should choose between:
EVENT/ENUM/TR >> An ellipsis (i.e. "...") indicates a point of extensibility that allows other child or attribute content.
RT/MEX                >> Ellipses (i.e., "...") indicate points of extensibility.
I recommend the RT/MEX text (with comma after i.e. removed) because it enables '...' to apply to something other than child or attribute content without restricting it.
Also for {3}:
EVENT>>      ... If a receiver does not recognize an extension, the receiver SHOULD NOT process the message and MAY fault.
TR/ENUM >> ... If a receiver does not recognize an extension, the receiver SHOULD ignore it.
RT/MEX>>     ... By default, if a receiver does not recognize an extension, the receiver SHOULD ignore the extension; exceptions to this processing rule, if any, are clearly indicated below.
These actually have quite different meanings:
a) the key issue is, on receipt of an extension that is not understood, should the extension be ignored or the whole message ignored (and perhaps fault).  Only the eventing spec suggests ignoring the complete message. Is there a specific reason that Eventing specified this behaviour?
b) the rt/mex text allows for behaviour other than the default ignore on receipt of an unrecognised extension.
I recommend that we adopt the RT/MEX text as this is the most accommodating unless there is a reason why this will not work for Eventing (a).

{4} WS-A MAP are defined and used by RT and MEX only so I recommend that we leave these only in these specs.  There is slight difference between the two texts when the soap binding is described - mex exploits the 's' prefix to mean either s11 or s12 in order to make the text more concise.  I recommend that we do the same in RT.




For convenience, here is example Notational Conventions text with the above labels {1}..{4} included.
------------------------------------------------------
XXX Notational Conventions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. {1}

This specification uses the following syntax to define normative outlines for messages:

   * The syntax appears as an XML instance, but values in italics indicate data types instead of values.

   * Characters are appended to elements and attributes to indicate cardinality:

        o  "?" (0 or 1)

        o  "*" (0 or more)

         o  "+" (1 or more)

   * The character "|" is used to indicate a choice between alternatives.

   * The characters "(" and ")" are used to indicate that contained items are to be treated as a group with respect to cardinality or choice.

   * The characters "[" and "]" are used to call out references and property names.{2}

   * An ellipsis (i.e. "...") indicates a point of extensibility that allows other child or attribute content. Additional children and/or attributes MAY be added at the indicated extension points but MUST NOT contradict the semantics of the parent and/or owner, respectively. If a receiver does not recognize an extension, the receiver SHOULD NOT process the message and MAY fault. {3}

   *  XML namespace prefixes (see Table xxx) are used to indicate the namespace of the element being defined.

In addition to Message Information Header properties [WS-Addressing], this specification uses the following properties to define messages: ...  {4}


________________________________



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






________________________________


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Received on Tuesday, 3 March 2009 16:54:55 UTC