Re: my action re: CR050: Counter Proposal

Jacek,

I think the spec needs clarification. I posted some suggestions 
elsewhere.[1]

I don't want to introduce processor-speak into the spec. The way to avoid 
that is to talk about validity of component model instances. However, we 
need to add information about the extensions supported. We should 
therefore define the concept of extended component models. 

"An extended component model is the core component model as described in 
Part 1 augmented with additional properties, components, and constraints 
as described by one or more extension specifications, such as those 
contained in Part 2."

Every extension specification MUST have a unique identifying namespace IRI 
that can be used for extension attributes and elements in documents.

I also propose that we add a property to the Description component:

{extensions} OPTIONAL: a set of IRIs that identify the supported 
extensions


Given these changes, we interpret REQUIRED extension properties as being 
required conditionally based on the presence of the extension IRI in the 
{extensions} property of the Description component.

>From an implementation point of view, a processor "knows" which extensions 
it supports, either a fixed list or configurable by some means. When it 
produces a component model, it lists the suported extensions on the 
{extensions} property. When it reads a document, it ignores unknown 
optional extensions attributes and elements, or reports an error if it 
encounters an unknown wsdl:required extension.

[1] http://lists.w3.org/Archives/Public/www-ws-desc/2006Jun/0024.html

Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca



Jacek Kopecky <jacek.kopecky@deri.org> 
Sent by: www-ws-desc-request@w3.org
06/08/2006 01:54 PM

To
WS-Description WG <www-ws-desc@w3.org>
cc

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