- 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