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