W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2006

RE: my action re: CR044

From: Rogers, Tony <Tony.Rogers@ca.com>
Date: Fri, 30 Jun 2006 10:07:35 +1000
Message-ID: <BEE2BD647C052D4FA59B42F5E2D946B3246B03@AUSYMS12.ca.com>
To: "Charlton Barreto" <charlton_b@mac.com>
Cc: "WS-Description WG" <www-ws-desc@w3.org>


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.

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?).

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 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 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
Received on Friday, 30 June 2006 00:07:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:40 GMT