Re: my action re: CR050: Counter Proposal

Hi Arthur, 

your formulation is so much better than mine. I support it fully. 8-)

Jacek

On Fri, 2006-06-09 at 12:42 -0400, Arthur Ryman wrote:
> 
> 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
> 
> 
>

Received on Friday, 9 June 2006 17:26:24 UTC