Re: my action re: CR044

Robert,

I think "is-applied-to" sounds awkward. I suggest "a binding implements an 
interface ..."

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



Roberto Chinnici <Roberto.Chinnici@Sun.COM> 
Sent by: www-ws-desc-request@w3.org
07/11/2006 08:33 PM

To
Jacek Kopecky <jacek.kopecky@deri.org>
cc
WS-Description WG <www-ws-desc@w3.org>
Subject
Re: my action re: CR044







With respect to my action re CR044, I suspect that the origin of the
confusion around interfaceless bindings lies with the use in part 2 of
the following unfortunate expression:

   "for all the Interface Operation components of any Interface component
    that uses this Binding component"

(see e.g 5.7.2, 6.4.2, 6.8.1, etc).

This frequently repeated snippet gives the impression that an interface
component *uses* a binding component. This is very different from the
picture conveyed by part 1.

According to part 1:
- a service has exactly one interface
- a service has one or more endpoints
- an endpoint has exactly one service (its parent)
- an endpoint has exactly one binding
- a binding has zero or one interfaces

Or, semi-graphically:

I <- S ->(many) E -> B ->(zero-or-one) I

So to state that an interface "uses" a binding is to assert a fairly
contrived relationship obtained by reversing and composing several
of the relationships defined by the spec. To be explicit:

an interface I uses binding B iff
  there is a service S such that
    there is an endpoint E such that
       parent(E) = S and binding(E) = B

I'd assert that it's more natural to say that a binding *is applied* to
an interface. The locus of application is an endpoint. Out of necessity,
at a given locus, a binding can only apply to one interface, the
interface of the service to which the endpoint belongs. If the binding
is non-generic, then that interface MUST be the same as the one the
binding refers to.

This long premise to introduce my proposal.

First of all, in part 1, section 2.15, we should make this is-applied-to
relationship explicit, by saying:

[[
The Binding component specified by the {binding} property of an Endpoint
is said to be applied to the Interface component which is the value of
the {interface} property of the {parent} Service component for the
Endpoint. According to the constraints given below, if this Binding
component has an {interface} property, its value MUST be the Interface
component the Binding component is applied to.
]]

Then in part 2 we should replace all uses of the misleading terminology
described earlier with the new one. E.g., in 5.7.2,

[[
{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
that uses this Binding component.
]]

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.
]]

It is also expedient to use the applies-to terminology in the sections
that introduce each new binding and to call out the relationship between
an Interface Operation component and the corresponding Binding Operation 
component (if any) at a locus of application (i.e. an endpoint).

E.g., for the SOAP Binding (section 5):

[[
The SOAP binding extension is designed with the objective of minimizing
what needs to be explicitly declared for common cases. This is achieved
by defining a set of default rules which apply to all Interface
Operation components of an Interface component, unless specifically
overridden on a per Interface Operation basis. Thus, if a given
Interface Operation component is not referred to specifically, then all
the default rules apply to that component. That is, per the requirements 
of [WSDL 2.0 Core Language], all operations of an Interface component
are bound according to this binding extension.
]]

becomes:

[[
The SOAP binding extension is designed with the objective of minimizing
what needs to be explicitly declared for common cases. This is achieved
by defining a set of default rules that affect all Interface Operation
components of an Interface component to which the SOAP binding extension
is applied, unless specifically overridden by a Binding Operation
component.
Thus, if a given Interface Operation component is not referred to
specifically by a Binding Operation component, then all the default
rules apply to that Interface Operation component. As a result, in
accordance with the requirements of [WSDL 2.0 Core Language], all
operations of an Interface component will be bound by this binding
extension.
]]

Similar modifications would be made to the sections concerning the
HTTP binding, in particular 6.8.2 which was the source of this issue.
(The text will be very similar to the one for 5.7.2 given above.)

All this in addition to the changes proposed by Jacek to correct any
material errors in 6.8.1 and 6.8.2.

Thanks,
Roberto


Jacek Kopecky wrote:
> Hi Charlton, I still find the text confusing, and I see that there is a
> problem with phrasing the relationship between interface-less bindings
> and the interfaces with which they are associated through an endpoint.
> 
> Here's my take (in the current editor's copy):
> 
> in 6.8.1 change "Interface Fault Reference" to "Binding Fault"
> 
> in 6.8.2, first bullet: change "Interface Message Reference and
> Interface Fault Reference components of any Interface component that
> uses this Binding component" to "Binding Message Reference and Binding
> Fault components in this Binding component"
> 
> in 6.8.2, second bullet, drop "and Binding Fault" - binding faults don't
> get transfer coding from defaults on operations that reference the
> faults
> 
> in 6.8.2, third bullet, add "If this property does not have a value, the
> value of the {http transfer coding default} property of the parent
> Binding Operation component is used, and if that has no value, the value
> from the Binding Operation component's parent Binding component is
> used."
> 
> This possibly affects other {...default} properties, not sure, too
> hurried to check. And finally, we should add somewhere a text about
> interface-less bindings, how they should be interpreted at runtime as
> though they did have the {interface} property with the right interface,
> and all the appropriate {binding operation} components using all the
> appropriate defaults.
> 
> Hope this helps,
> 
> Jacek
> 
> On Fri, 2006-06-30 at 03:13 +0100, Charlton Barreto wrote:
>> Hi Tony,
>>
>> On Friday, June 30, 2006, at 01:07AM, Rogers, Tony <Tony.Rogers@ca.com> 
wrote:
>>
>>> Maybe I've misunderstood what Jacek's point was, but I thought he was
>>> pointing out that Interfaces don't have Bindings, and hence don't have
>>> transfer codings. Thus we must rephrase in terms that do not talk of
>>> transfer codings on Interfaces.
>> Agreed. As such, the language I've written below doesn't present 
Interfaces as having Bindings (and therefore Transfer Codings). Rather, it 
presents the binding rules (including matching the interface name 
associated with the Binding) where the Transfer Coding property 
values/defaults are applied. It is possible that the way it is written is 
confusing, so I have modified the language below as a clarification. 
>>
>>> The Interface is connected to the Binding at the Endpoint, and 
therefore
>>> it should be the Endpoint which is receiving the transfer coding.
>>> Certainly, a Binding may be specific to an Interface, but that doesn't
>>> attach the Binding to the Interface. Indeed, one might have multiple
>>> Bindings which specify a given Interface. When a Binding specifies an
>>> Interface, that means that it can only appear on Endpoints in a 
Service
>>> which specifies that Interface (or, possibly, an Interface which 
extends
>>> that Interface?).
>> Agreed. The language below (as clarified, please review :-)) implicitly 
states this point. My understanding is that the point is made as is 
(pursuant of language which explicity states the meaning of a Binding 
specifying an Interafce). 
>>
>> However, if this is not clear enough as is, we may need to better 
elaborate this in these paragraphs. Please let me know what you think. 
>>
>> Best,
>>
>> -Charlton. 
>>
>>> Or am I misunderstanding something?
>>>
>>>
>>> Tony Rogers
>>> tony.rogers@ca.com
>>>
>>> -----Original Message-----
>>> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] 
On
>>> Behalf Of Charlton Barreto
>>> Sent: Friday, 30 June 2006 3:03
>>> To: Charlton Barreto
>>> Cc: WS-Description WG
>>> Subject: Re: my action re: CR044
>>>
>>>
>>> Pursuant to our discussion on tonight's telecon re: CR044 and CR055, I
>>> reviewed Jacek's clarification on HTTP Transfer Coding
>>> (http://lists.w3.org/Archives/Public/www-ws-desc/2006Jun/0032.html). I
>>> have proceeded to update the references to the HTTP Transfer Coding as
>>> mentioned in the CR044 proposed language. In addition, with this CR044
>>> proposed language and my understanding of this clarification, I 
believe
>>> we need an additional sentence to the proposed Binding Rules 
description
>>> to capture this clarification (for the Binding component level {http
>>> transfer coding default}; I see the clarification for the Binding
>>> Operation component level {http transfer coding default} as implicit 
in
>>> the below proposal). 
>>>
>>> As such I would like to propose the following updated text for the
>>> proposed additional section <6.8.3 Binding Rules> as follows: 
>>>
>>> <For a given Interface component, if there is a Binding component a) 
whose
>>> {interface} property matches the component in question, b) which 
defines a Binding
>>> Fault and c) where that Binding Fault's {http transfer coding} 
property has a value,
>>> then the HTTP Transfer Coding is the value of the {http transfer
>>> coding} property. Otherwise, the HTTP Transfer Coding is the value of
>>> the Binding component's {http transfer coding default}, if any. Note
>>> that this {http transfer coding default} applies to the BindingFault 
and
>>> BindingMessageReference components. 
>>>
>>> For a given Interface Operation component, if there is a Binding
>>> Operation component whose {interface operation} property matches the
>>> component in question and its {http transfer coding} property has a
>>> value, then the HTTP Transfer Coding is the value of the {http 
transfer
>>> coding} property. Otherwise, the HTTP Transfer Coding is the value of
>>> the Binding Operation component's {http transfer coding default}, if
>>> any.>
>>>
>>> -Charlton.
>>>
>>> On Thursday, June 29, 2006, at 03:47PM, Charlton Barreto
>>> <charlton_b@mac.com> wrote:
>>>
>>>> Following on my initial assessment and working suggestions for CR044, 
I
>>> have worked on some language which I believe will make implicit the 
use
>>> of default properties to support interface-less bindings where the 
{http
>>> transfer coding default} and {http query parameter separator default}
>>> properties are described. 
>>>> Add a section <6.7.2.3 Binding Rules> to section 6.7.2 Serialization 
as
>>> "application/x-www-form-urlencoded" with the following:
>>>> <For a given Interface Operation component, if there is a Binding 
>>>> Operation component whose {interface operation} property matches the 
>>>> component in question and its {http query parameter separator} 
property
>>>> has a value, then the Query Parameter Separator is the value of the 
>>>> {http query parameter separator} property. Otherwise, the Query 
>>>> Parameter Separator is the value of the Binding component's {http 
query
>>>> parameter separator default}.>
>>>>
>>>> Add a section <6.8.3 Binding Rules> to section 6.8 Specifying the
>>> Transfer Coding with the following:
>>>> <For a given Interface component, if there is a Binding component 
whose
>>> {interface} property matches the component in question defines a 
Binding
>>> Fault, and that Binding Fault's {http transfer coding} property has a
>>> value, then the HTTP Transfer Coding for all Interface Message 
Reference
>>> and Interface Fault Reference components of any Interface component
>>> using this Binding component is the value of the {http transfer 
coding}
>>> property. Otherwise, the HTTP Transfer Coding is the value of the
>>> Binding component's {http transfer coding default}, if any.
>>>> For a given Interface Operation component, if there is a Binding 
>>>> Operation component whose {interface operation} property matches the 
>>>> component in question and its {http transfer coding} property has a 
>>>> value, then the HTTP Transfer Coding for all Binding Message 
Reference 
>>>> and Binding Fault components of this Binding Operation component is 
the
>>>> value of the {http transfer coding} property. Otherwise, the HTTP 
>>>> Transfer Coding is the value of the Binding Operation component's 
{http
>>>> transfer coding default}, if any.>
>>>>
>>>> By including this "Binding Rules" language where these properties
>>> apply, I believe that the use of these properties is clearly 
elaborated
>>> even if one doesn't follow the progression from the earlier language 
on
>>> {soap mep default} and {http method default}. 
>>>> Please review this and let me know if you have any feedback.
>>>>
>>>> -Charlton. 
>>>>
>>>>
>>>> On Thursday, June 15, 2006, at 05:00PM, Charlton Barreto
>>> <charlton_b@mac.com> wrote:
>>>>> I accepted an action on last week's telecon to review the text
>>> appropriate to CR044 in Part 2 to ensure that it adequately explained
>>> the rationale for default properties in support of interface-less
>>> bindings. 
>>>>> Per my review, the language presenting the use of default rules for
>>> each binding (section 5 for SOAP 1.2 and 6 for HTTP), the elaboration 
on
>>> binding rules for SOAP MEP Selection in section 5.10.3, and the
>>> elaboration on binding rules for HTTP Method Selection in section 
6.3.1,
>>> in combination, clearly explain the use of default properties to 
support
>>> interface-less bindings. I would recommend some wordsmithing in 
section
>>> 6.3.1 for additional clarity and smoother reading (changes in <>):
>>>>> "For a given Interface Operation component, if there is a Binding
>>> Operation component whose {interface operation} property matches the
>>> component in question and its {http method} property has a value, then
>>> <the HTTP request method is> the value of the {http method} property."
>>>>> "Otherwise, <the HTTP request method is> the value of the Binding
>>> component's {http method default}, if any."
>>>>> Yet, the wording regarding the elaboration on the use of {http
>>> transfer coding} and {http query parameter separator} could use some
>>> additional clarification in my opinion - although one can logically
>>> follow the progression from the previous elaboration on HTTP binding
>>> rules, it may not be obvious enough. I will provide some proposed text
>>> for this soon.
>>>>> -Charlton.
>>> --
>>> charlton_b@mac.com
>>> +1.650.222.6507 m
>>> +1.415.692.5396 v
>>>
>>>
>>>
>>>
>>
>> --
>> charlton_b@mac.com
>> +1.650.222.6507 m
>> +1.415.692.5396 v
>> http://charltonb.typepad.com