my action re: CR044

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.rogersca.com

-----Original Message-----
From: www-ws-desc-requestw3.org
[mailto:www-ws-desc-requestw3.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
 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_bmac.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
 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_bmac.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_bmac.com
+1.650.222.6507 m
+1.415.692.5396 v

Hi Tony,

On Friday, June 30, 2006, at 01:07AM, Rogers, Tony
<Tony.Rogersca.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.rogersca.com
>
>-----Original Message-----
>From: www-ws-desc-requestw3.org
[mailto:www-ws-desc-requestw3.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
> 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_bmac.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
> 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_bmac.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_bmac.com
>+1.650.222.6507 m
>+1.415.692.5396 v
>
>
>
>


--
charlton_bmac.com
+1.650.222.6507 m
+1.415.692.5396 v
http://charltonb.typepad
.com