Re: my action re: CR044

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

Received on Thursday, 29 June 2006 14:47:32 UTC