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

JJ,

Thx for the comments. I agree with the edits.

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



Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr> 
Sent by: www-ws-desc-request@w3.org
09/21/2006 09:06 AM

To
Arthur Ryman/Toronto/IBM@IBMCA
cc
www-ws-desc@w3.org
Subject
Re: Revised Proposed Part 1 Text for REQUIRED Extension Properties:  Model 
vs  Instance







I like this. Quite akin to how SOAP extensions can override the SOAP 
processing model. So it's good to see some similarity in W3C specs.

Some nitty-gritty:
- as defined by the WSDL 2.0 Core Language specification >>(this 
specification)<<
- is only REQUIRED >>when<< the extension

JJ.

Arthur Ryman wrote:
>
> 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