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