- From: Roberto Chinnici <Roberto.Chinnici@Sun.COM>
- Date: Wed, 01 Oct 2003 09:45:20 -0700
- To: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
- Cc: "Amelia A. Lewis" <alewis@tibco.com>, jmarsh@microsoft.com, www-ws-desc@w3.org
Sanjiva Weerawarana wrote: > NOTE: I changed the subject to reflect the on-going discussion. > > >>I still support your original position, hence I disagree with making >>this pattern normative. How about the compromise of having the pattern >>Amy proposes in a non-normative appendix to the patterns spec? We define >>it properly, assign it a URI, use it to elucidate the patterns >>framework, make it available for anybody to use it (if they have >>a binding for it, that is), but it's *not* normative. > > > I think this is ok .. and basically this is all we can do for any > patttern. It is however normative to the point that if someone > uses that pattern URI then the semantics MUST be exactly as specified. > Beyond that there's no real "normativeness" for pattern URIs. Some > patterns will of course get exercised in bindings we do (i.e., the > bindings will only be applicable to those patterns), but that's as > far as it goes. I think we are in agreement. If a pattern is non-normative, then a tool doesn't have to recognize it. (It's not even a MAY recognize. The normative spec doesn't even know about the pattern.) If the tool does recognize it, though, it must follow the appropriate specification, like for any other extension. I'd also expect the appendix to have a title similar to the existing appendix E, e.g. "Examples of Specifications of Alternative Message Patterns (Non-Normative)". Roberto
Received on Wednesday, 1 October 2003 12:43:55 UTC