W3C home > Mailing lists > Public > public-ws-policy-eds@w3.org > May 2007

Change summary for section 5.5 (ACTION-268)

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Fri, 18 May 2007 15:17:57 -0400
Message-Id: <987F3E04-2E21-4E51-89B1-842CFB3213E8@nokia.com>
Cc: Hirsch Frederick <frederick.hirsch@nokia.com>
To: WS-Policy Editors W3C <public-ws-policy-eds@w3.org>

This is my summary of changes to section for 5.5 to include in  
editors report to the Work Group, to close my portion of editors  

(1) Updated section 5.5 "Designating Optional Behaviors"

(Note this used to be section 4.5 but we added new section  
summarizing Good Practices and a new subsection Designating Ignorable  
Behavior" so the number is changed to 5.5).

(1a) Updated section 5.5.1, "Optional behavior in Compact authoring"
Added Good Practices and updated text and added examples to go with  
the added Good practices;
Good practice 16: Assertion XML should allow use of wsp:Optional  

Good practice 17: Assertion description should explicitly indicate  
that wsp:Optional is allowed.

These good practices correspond to  G7 and G8 as proposed to the Work  
Group [1]. The text of the original good practice proposal is  
included in the detail of the Good Practice added to the Guidelines  

(1b) Updated section 5.6.2, "Optional behavior at runtime"

Reorganized section to give introduction followed by good practices  
followed by examples. In process performed editorial clean up of  
language. Made explicit the good practices that were implicit in the  
original text:

Good practice 18: Limit use of Optional Assertions

Good practice 19: Consider entire message exchange pattern when  
specifying Assertions that may be optional

These two were added based on the implicit practices in the original  
guidelines text.

Good practice 20: Indicate use of an Optional Assertion

"When a given behavior may be optional, it must be possible for both  
message participants to determine that the assertion is selected by  
both parties, either out of band or as reflected by the message  

This is a revision of the Best Practice present previously,

Best Practice: Optional Assertion Authors should explicitly state how  
the behavior that is enabled by the assertion would be engaged when  
they are designing their assertion, whether by specific headers or  
some other means

Added informative reference for MTOMPolicy to References and linked  
from example in this section.

regards, Frederick

Frederick Hirsch

[1] http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/ 
Received on Friday, 18 May 2007 19:18:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:27:52 UTC