2002/ws/desc/wsdl20 wsdl20-bindings.xml,1.106,1.107

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

Modified Files:
	wsdl20-bindings.xml 
Log Message:
Removed AD feature


Index: wsdl20-bindings.xml
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-bindings.xml,v
retrieving revision 1.106
retrieving revision 1.107
diff -C2 -d -r1.106 -r1.107
*** wsdl20-bindings.xml	29 Jul 2004 17:04:23 -0000	1.106
--- wsdl20-bindings.xml	30 Jul 2004 06:44:42 -0000	1.107
***************
*** 1654,1718 ****
        <!-- +++++++++ -->
  
-       <div2 id="http-ad-serialization">
- 	<head>
- 	  Application data serialization as HTTP headers
- 	</head>
- 
- 	<ednote>
- 	  <edtext>This needs to be moved to Part 2</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 indicates a &EII;
- 	that 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. Attributes on data elements
- 	are ignored.</p>
- 
- 	<p>Each such &EII; is serialized as follows:</p>
- 	<ulist>
- 	  <item><p>The HTTP header name used is the &EII; local
- 	  name. The &EII; local name MUST follow the field-name
- 	  production rules as specified in section 4.2 of <bibref
- 	  ref="RFC2616"/>; if not, the &EII; MUST be ignored. 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 in UTF-8. If this serialization is NOT possible,
- 	  then the &EII; MUST be ignored.</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 <bibref
- 	ref="WSDL-PART1"/>, or out-of-band agreements.  The contents
- 	of each such HTTP header will be placed in a child element of
- 	the data property. Each child &EII; is generated by using the
- 	HTTP header name as the &EII; local name and the HTTP header
- 	value as the &EII; value.</p>
- 
- 	<note>
- 	  <p>
- 	    The &EII; local name who's the parent node of the &EII;s
- 	    received as well as the namespace of those &EII;s are
- 	    implementation-specific.
- 	  </p>
- 	</note>
- 
-       </div2>
- 
-       <!-- +++++++++ -->
- 
        <div2 id="http-fault-decl">
          <head>Specifying HTTP Error Codes for Faults</head>
--- 1654,1657 ----
***************
*** 2874,2880 ****
  -->
  <tr>
!  <td>20040729</td>
   <td>HH</td>
!  <td>Clarified AD Feature serialization in HTTP.</td>
  </tr>
  <tr>
--- 2813,2819 ----
  -->
  <tr>
!  <td>20040730</td>
   <td>HH</td>
!  <td>Removed AD Feature HTTP serialization.</td>
  </tr>
  <tr>

Received on Friday, 30 July 2004 02:44:48 UTC