2002/ws/desc/wsdl20 wsdl20-bindings.xml,1.104,1.105

Update of /sources/public/2002/ws/desc/wsdl20
In directory homer:/tmp/cvs-serv9904

Modified Files:
	wsdl20-bindings.xml 
Log Message:
Oops, the AD Feature HTTP serialization was missing.
It's not complete though


Index: wsdl20-bindings.xml
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-bindings.xml,v
retrieving revision 1.104
retrieving revision 1.105
diff -C2 -d -r1.104 -r1.105
*** wsdl20-bindings.xml	28 Jul 2004 07:33:10 -0000	1.104
--- wsdl20-bindings.xml	29 Jul 2004 10:20:07 -0000	1.105
***************
*** 64,69 ****
  	document-oriented or procedure-oriented information. WSDL
  	Version 2.0 Bindings describes how to use WSDL in conjunction
! 	with SOAP 1.2 <bibref ref="SOAP12-PART1"/>, HTTP/1.1
! 	<bibref ref="RFC2616"/> and other versions of HTTP.  This
  	specification depends on WSDL Version 2.0 <bibref ref="WSDL-PART1"/>.
        </p>
--- 64,69 ----
  	document-oriented or procedure-oriented information. WSDL
  	Version 2.0 Bindings describes how to use WSDL in conjunction
! 	with SOAP 1.2 <bibref ref="SOAP12-PART1"/> and HTTP/1.1
! 	<bibref ref="RFC2616"/> (as well as other versions of HTTP).  This
  	specification depends on WSDL Version 2.0 <bibref ref="WSDL-PART1"/>.
        </p>
***************
*** 1024,1028 ****
        <p>The HTTP binding described in this section is an extension for
  <bibref ref="WSDL-PART1"/> to enable Web Services applications to use
! HTTP 1.1 <bibref ref="RFC2616"/> and HTTPS <bibref ref="RFC2818"/>.  This binding extends WSDL 2.0
  by adding properties to the component model defined in <bibref ref="WSDL-PART1"/>. In addition an XML Infoset representation
  for these additional properties is provided, along with a mapping from
--- 1024,1028 ----
        <p>The HTTP binding described in this section is an extension for
  <bibref ref="WSDL-PART1"/> to enable Web Services applications to use
! HTTP 1.1 <bibref ref="RFC2616"/> (as well as other versions of HTTP) and HTTPS <bibref ref="RFC2818"/>.  This binding extends WSDL 2.0
  by adding properties to the component model defined in <bibref ref="WSDL-PART1"/>. In addition an XML Infoset representation
  for these additional properties is provided, along with a mapping from
***************
*** 1123,1126 ****
--- 1123,1138 ----
        <!-- +++++++++ -->
  
+       <div2 id="_http_binding_supported_feature">
+         <head>Supported features</head>
+ 
+ 	<p>This binding specification supports the Application Data
+ 	Feature (<attval>&AD-FEATURE;</attval>) as defined is <bibref
+ 	ref="WSDL-PART2"/> (see <specref
+ 	ref="http-ad-serialization"/>).</p>
+ 
+       </div2>
+ 
+       <!-- +++++++++ -->
+ 
        <div2 id="_http_binding_default_rules">
          <head>Default Binding Rules</head>
***************
*** 1437,1440 ****
--- 1449,1455 ----
  	  location of the bound operation.</p>
  
+ 	  <p>"Out-of-band" application data is serialized as explained
+ 	  in <specref ref="http-ad-serialization"/>.</p>
+ 
          </div3>
          <div3 id="http-operation-decl-relate">
***************
*** 1652,1655 ****
--- 1667,1725 ----
        </div2>
  
+       <!-- +++++++++ -->
+ 
+       <div2 id="http-ad-serialization">
+ 	<head>
+ 	  Application data serialization as HTTP headers
+ 	</head>
+ 
+ 	<ednote>
+ 	  <edtext>Note that there is still some ed notes in there.</edtext>
+ 	</ednote>
+ 
+ 	<p>This section specifies how to transmit "out of band"
+ 	application data, defined in the Application Data Feature in
+ 	<bibref ref="WSDL-PART2"/>, as HTTP headers.</p>
+ 
+ 	<p>If the property <attval>&AD-FEATURE-DATA-P;</attval> has a
+ 	value for a message to be serialized as an HTTP message, then
+ 	each of the top-level child &EII;s indicate a possible &EII;
+ 	that SHOULD [ed: MUST?] be turned into an HTTP header.</p>
+ 
+ 	<p>Only &EII; of type type <attval>xs:string</attval> type,
+ 	including <attval>xs:anyURI</attval>, may be serialized. All
+ 	complex data types are ignored. Each such &EII; is serialized
+ 	as follows:</p>
+ 	<ulist>
+ 	  <item><p>The HTTP header name used is the &EII; local
+ 	  name. If an HTTP header corresponding to the &EII; local
+ 	  name is set by a mechanism other than the Application Data
+ 	  Feature, such as the HTTP stack or another feature, then an
+ 	  error MUST be raised.</p></item>
+ 	  <item><p>The HTTP header content is serialized from the
+ 	  &EII; value. Any attributes on data elements are
+ 	  ignored. Where the &EII; contains content that cannot be
+ 	  directly encoded per the HTTP specification, it MUST be
+ 	  escaped. [ed: how?]</p></item>
+ 	</ulist>
+ 
+ 	<p>It is the responsibility of the receiving node to determine
+ 	which, if any, HTTP headers will populate the
+ 	<attval>&AD-FEATURE-DATA-P;</attval> property. Typically this
+ 	will be accomplished via using some metadata, such as an
+ 	understanding of a &lt;constraint&gt; specified in WSDL [ed:
+ 	constraint is not defined], or out-of-band agreements.  The
+ 	contents of each such HTTP header will be placed in a child
+ 	element of the data property [ed: should we define a
+ 	particular "wrapper" element here as the top level one?]. Each
+ 	child &EII; is generated by using the HTTP header name as the
+ 	element information item local name [ed: should we define a
+ 	particular namespace?] and the HTTP header value as the &EII;
+ 	value.</p>
+ 
+       </div2>
+ 
+       <!-- +++++++++ -->
+ 
        <div2 id="http-fault-decl">
          <head>Specifying HTTP Error Codes for Faults</head>
***************
*** 2811,2814 ****
--- 2881,2889 ----
  -->
  <tr>
+  <td>20040729</td>
+  <td>HH</td>
+  <td>Added AD Feature support in HTTP binding.</td>
+ </tr>
+ <tr>
   <td>20040727</td>
   <td>HH</td>

Received on Thursday, 29 July 2004 06:20:11 UTC