- From: Rogers, Tony <Tony.Rogers@ca.com>
- Date: Fri, 9 Jun 2006 14:16:30 +1000
- To: "Jacek Kopecky" <jacek.kopecky@deri.org>, "WS-Description WG" <www-ws-desc@w3.org>
- Message-ID: <BEE2BD647C052D4FA59B42F5E2D946B317B54F@AUSYMS12.ca.com>
We were discussing this on the implementers' call, too. Arthur put forward the position that awareness of an extension may add required properties to the component model, even if the extension is not used by the WSDL infoset being processed. That's exactly as you described it (even though you don't like that idea). Consider WS-Addressing - awareness of this extension (or should that be, "these extensions"?) means that the {action} property (which is required) is added to the component model. So I don't believe we can avoid this situation. Tony ________________________________ From: www-ws-desc-request@w3.org on behalf of Jacek Kopecky Sent: Fri 09-Jun-06 3:54 To: WS-Description WG Subject: my action re: CR050 Hi all, I got an action to respond to Jonathan regarding CR050 which we today agreed to close with no change to the spec. However, we already discussed CR050 on the call on 2006/06/01 and we concluded that if an extension is supported, it must obey the constraints, so if safety is supported it must be present on all operations. (Basically status quo.) However, we didn't close the issue because we felt that we needed more discussion on how to make the spec clearer about this. Let me step forward and suggest how we could perhaps concretely clarify this. It seems that the best place to do this is in part 1 section 6.3 Extensibility Semantics [2]. There are already three notes at the end of this section, and I'm suggesting a fourth one, so maybe it could be restructured somehow, but I frankly don't know how. 8-) To resolve issue CR050, I suggest we add this note to 6.3: Note: The presence of an optional extensibility element or attribute may introduce new properties to the component model. It may be useful for the extensions to define default values for the properties for the case when the extensibility element or attribute is not present. For example, _Operation safety_ extension defined in part 2 specifies an attribute wsdlx:safe and adds the required property {safety}, defaulting to "false" if the attribute is not present on an interface operation. This behavior suggests that mere understanding (or awareness) of an extension by a processor can amend the component model, and that different processors may parse the same WSDL document into different component models, if they support different optional extensions. Since optional extensions must not invalidate the meaning of WSDL documents (see section 6.1.1.), the different component models resulting from differing support for optional extension should, on some level, be equivalent. However, such component model differences need to be considered if component models from different processors are being compared, for example for interoperability testing. (end of note) It's complex, abstract, and it uses the term processor which we eschewed, if I remember correctly, but I don't see now how it could be clarified better. Or maybe we could just make {safety} optional and clarify in 6.3 that optional extensions (or any extensions, most probably) cannot introduce REQUIRED properties because the absence of an extension from the WSDL document makes the properties absent as well. Sure hope this makes sense, Jacek [1] http://lists.w3.org/Archives/Public/www-ws-desc/2006Jun/att-0004/20060601-ws-desc-minutes.html [2] http://www.w3.org/TR/wsdl20/#extensibility-semantics
Received on Friday, 9 June 2006 04:17:01 UTC