Re: my action re: CR044

Hi Jacek,

Please see my comments below.

Roberto

Jacek Kopecky wrote:
>> becomes
>>
>> [[
>> {soap mep default} OPTIONAL. A xs:anyURI, which is an absolute IRI as
>> defined by [IETF RFC 3987], to the Binding  component.† The value of
>> this property identifies the default SOAP Message Exchange Pattern (MEP) 
>> for all the Interface Operation components of any Interface component to 
>> which this Binding component is applied.
>> ]]
> 
> The thing is that Interface Operation components do not have (nor care
> about) SOAP Message Exchange Pattern.
> 
> I was suggesting for the HTTP transfer coding default (and implicitly
> for all similar places, e.g. SOAP MEP default) that the binding sections
> drop all mentions of interface components, and that we say somewhere
> that bindings that don't have (some) binding operation components get
> all the appropriate binding operations at runtime, virtually (so to
> speak), when the binding is applied to some interface.

Actually I don't see it as a problem with the text I proposed that
it mentions Interface and Interface Operation components. After all,
at runtime the machinery implementing a binding extension will be tasked
with handling messages associated with a particular operation of a
given interface. In the above paragraph, we refer to the corresponding
components because that's the spec-blessed way we have to refer to
interfaces and operations.

Moreover, since the language we use is

   "the value of this property identifies the default X for all Y
    components"

without curly braces or anything like that, I don't think there'll
be any confusion as to whether we are defining a property (in the
component model sense) of the Interface Operation or Interface 
components, or just providing instructions for binding extension
implementors.

Your suggestion of introducing virtual binding components, to be used
whenever a generic binding is applied to a specific interface, is
interesting but I'm a bit nervous about introducing this kind of
machinery at this late stage. I suspect it may trigger a flurry of
new issues of its own.

> Currently, we say this in 2.9.1:
> 
>         A Binding component that defines bindings for an Interface
>         component MUST define bindings for all the operations of that
>         Interface component.† The bindings may occur via defaulting
>         rules which allow one to specify default bindings for all
>         operations (see, for example [WSDL 2.0 Adjuncts]) or by directly
>         listing each Interface Operation component of the Interface
>         component and defining bindings for them. Thus, it is an error
>         for a Binding component to not define bindings for all the
>         Interface Operation components of the Interface component for
>         which the Binding component purportedly defines bindings for.
> 
> This could be expanded to interface-less binding like this:
> 
>         A Binding component that does not specify any Interface
>         component will be applied to an Interface component through its
>         use by some Endpoint component (see 2.15).

Yes, but non-generic bindings too are only applied to an interface
through their use by some Endpoint component, so this sentence may
be a bit misleading.

>                                                     In this case all
>         bindings occur via default rules and it is an error for a
>         Binding component not to have an Interface component if the
>         default rules of the binding type are not sufficient to bind all
>         aspects of the Interface Operation and Interface Fault
>         components.

I presume that by "default rules" you mean "rules that can be expressed
without requiring any Binding Operation components", since it is
possible to add extensions to generic bindings at the Binding component
level. Normally, I'd interpret "default rules" to mean "rules that apply
if the developer doesn't say anything at all".

All nitpicking aside, I'm in favor of adding a paragraph specifically
addressing generic bindings to 2.9.1.

Received on Wednesday, 12 July 2006 17:05:14 UTC