RE: my action re: CR050

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