Revised Proposed Part 1 Text for REQUIRED Extension Properties: Model vs Instance

Recall that as implementors were working with the extensions in Part 2, 
the meaning of the word REQUIRED caused some confusion. The problem was 
that since extensions are themselves optional, what did it mean for an 
extension to contain a REQUIRED property? The answer that everyone agrees 
with is that you have to state up front what extensions are in effect 
before you can interpret the word REQUIRED.  Therefore when reading an 
extension spec, you interpret REQUIRED to mean that the property is 
REQUIRED if and only if the extension is in effect.

Implementors further noticed that some properties only made sense if other 
extensions or properties or property values were present. This led to the 
idea that extensions should explicitly specify co-occurence contraints. 
For example, the SOAP binding make use of the HTTP binding, but the HTTP 
properties should only be present if the SOAP binding specifies a 
transport of HTTP. This type of property should be marked as OPTIONAL and 
the extensions specification should add constraints that define when it is 
required.

Furthermore, it was realized that we need to allow one extension to 
override the semantics of another extension. For example, one extension 
may demote a REQUIRED property in one extension to OPTIONAL status. This 
is fine as long as the combined set of extensions in effect are mutually 
consistent.

I therefore proposed that we spell these considerations out explicitly and 
I proposed text [1]. We discussed this at length in the July 20 telecon 
[2]. I've update the proposed text below, but I'd like to resolve one 
additional terminology issue.

One of the issues that came up was my use of the terms "component model" 
and "component model instance". Glen felt these terms were used 
incorrectly. He felt that a "component model" was the set of components 
that were created from a WSDL document, i.e. that Glen's model is what I 
was calling an instance. I've thought about this and would like to defend 
my use of the terms.

I think we should be using the term "model" in the same sense as it is 
used by OMG, e.g. in Model-Driven Development, or Unified Modelling 
Language (UML). In UML one creates "models" of systems, e.g. by drawing 
class diagrams. The correspondence with WSDL is that a component spec is 
like a class diagram. Our core spec contains a set of component specs and 
it therefore like a UML class model. In fact our primer contains an 
infoset diagram [3] that looks very much like a UML class diagram. I 
therefore propose that we adopt the meaning of "component model" to be the 
specification and not the set of components from a given WSDL document.

If we agree with the use of "component model" to mean the core 
specification as defined by Part 1, and we agree that in order to 
interpret REQUIRED for extensions we need to state what extensions are in 
effect, then I would like to propose that we adopt the definition of 
"extended component model" to mean the core component model PLUS the set 
of extensions that are in effect.

Here's the updated text:

6.4 Validity of Extended Component Model Instances

As stated above, WSDL 2.0 provides a component model extensibility 
mechanism which allows new properties and components to be specified. An 
extension specification may also add new constraints or modify existing 
ones. The validity of a component model instance is therefore dependent on 

the set of extension specifications that it is asserted to conform to. 

An extended component model is the component model as defined by the WSDL 
2.0 
Core Language specification together with a set of extension 
specifications that are in effect. A component model instance is valid 
with respect to an 
extended component model if it conforms to the core language and the
set of extension specifications that are in effect, with the provision 
that any extension 
specification may explicitly override any constraint in another 
specification.

6.4.1 Semantics of REQUIRED Properties in Extended Component Models

When an extension specification defines a property to be REQUIRED, this is 

to be understood that the property is only REQUIRED the extension 
specification is in effect. 
An extension specification may override the REQUIRED constraint on 
any property defined in another specification and make it OPTIONAL.  Thus, 

a property is only REQUIRED when the following conditions hold:

* the extension specification is in effect

* no other extension specification in the extension component model 
overrides this constraint

An extension specification may also define co-occurence constraints that 
further qualify the conditions under which an OPTIONAL property is 
required. 


[1] http://lists.w3.org/Archives/Public/www-ws-desc/2006Jul/0076.html
[2] http://www.w3.org/2006/07/20-ws-desc-minutes.html#action03
[3] 
http://www.w3.org/TR/2006/CR-wsdl20-primer-20060327/#wsdl-infoset-diagram

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