- From: Hugo Haas <hugo@dev.w3.org>
- Date: Fri, 30 Jul 2004 06:44:44 +0000
- To: public-ws-desc-eds@w3.org
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 <constraint> 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