W3C home > Mailing lists > Public > public-ws-resource-access-notifications@w3.org > April 2009

WWW/2002/ws/ra/edcopies wst.html,1.30,1.31 wst.xml,1.26,1.27

From: Doug Davis via cvs-syncmail <cvsmail@w3.org>
Date: Tue, 21 Apr 2009 00:40:42 +0000
To: public-ws-resource-access-notifications@w3.org
Message-Id: <E1Lw42U-0006By-Nm@lionel-hutz.w3.org>
Update of /w3ccvs/WWW/2002/ws/ra/edcopies
In directory hutz:/tmp/cvs-serv23711

Modified Files:
	wst.html wst.xml 
Log Message:
6730


Index: wst.xml
===================================================================
RCS file: /w3ccvs/WWW/2002/ws/ra/edcopies/wst.xml,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -d -r1.26 -r1.27
--- wst.xml	21 Apr 2009 00:04:17 -0000	1.26
+++ wst.xml	21 Apr 2009 00:40:40 -0000	1.27
@@ -470,21 +470,6 @@
         <p>A Get request MUST be targeted at the resource whose representation is
  desired as described in <specref ref="Notations_and_Terminology"/> of
 this specification.</p>
-        <p>As per
-the SOAP processing model, other specifications may introduce various types
-of extensions to the semantics of this message which are enabled through
-headers tagged with <code>s:mustUnderstand="true"</code>. Such extensions
-may define how resource or subsets of it are to be retrieved or transformed
-prior to retrieval. Specifications which define such extensions MUST
-allow processing the basic Get request message without those
-extensions. Since the response may not be sent to the original sender,
-extension specifications should consider adding a corresponding SOAP header
-value in the response to signal to the receiver that the extension is being
-used.</p>
-        <p>Implementations may respond with a fault message using the standard fault
-codes defined in WS-Addressing (e.g., wsa:ActionNotSupported). Other
-components of the outline above are not further constrained by this
-specification.</p>
         <p>If the resource accepts a Get request, it MUST reply with a response of
 the following form:</p>
         <example>
@@ -632,30 +617,11 @@
         <p>
          A Put request MUST be targeted at the resource whose representation is
          desired to be replaced, as described in 
-         <specref ref="Notations_and_Terminology"/> of this specification. As
-         per the SOAP processing model, other specifications MAY 
-         introduce various types of extensions to this message which 
-         are enabled through headers tagged with 
-         <code>s:mustUnderstand="true"</code>. Such extensions may require
-         that a full or partial update should be accomplished using symbolic,
-         instruction-based, or other methodologies.
-        </p>
-
-        <p>
-         Extension specifications MAY also define extensions to the 
-         original Put request, enabled by OPTIONAL SOAP headers, which 
-         control the nature of the response, as discussed in remarks on 
-         the PutResponse below.
-        </p>
-
-        <p>
-         Specifications which define any of these extensions MUST allow 
-         processing the Put message without such extensions.
+         <specref ref="Notations_and_Terminology"/> of this specification.
         </p>
 
         <p>
-         In addition to the standard fault codes defined in WS-Addressing,
-         implementations MAY use the fault code wst:InvalidRepresentation 
+         Implementations MAY use the fault code wst:InvalidRepresentation 
          if the presented representation is invalid for the target resource. 
          See <specref ref="Faults"/>. Other components of the outline above are not 
          further constrained by this specification.
@@ -703,20 +669,6 @@
                case, however.
               </p>
 
-              <p>
-               Extension specifications MAY define extensions to the original 
-               Put request, enabled by OPTIONAL header values, which 
-               specifically control the presence, absence, or format of the 
-               updated representation or other child elements in the 
-               PutResponse in order to optimize the response.  In the 
-               absence of such headers, the behavior MUST be as described
-               above. Specifications which define any of these extensions MUST
-               allow processing the Put message without such extensions. 
-               Since the response may not be sent to the original sender, 
-               extension specifications should consider adding a 
-               corresponding SOAP header value in the response to signal 
-               to the receiver that the extension is being used.
-              </p>
             </def>
           </gitem>
         </glist>
@@ -786,13 +738,6 @@
         <head>Delete</head>
         <p>This specification defines one Web service operation (Delete) for deleting
 a resource in its entirety.</p>
-        <p>Extension specifications MAY define extensions to the Delete request,
-enabled by OPTIONAL header values, which specifically control preconditions
-for the Delete to succeed and which may control the nature or format of the
-response. Since the response may not be sent to the original sender,
-extension specifications should consider adding a corresponding SOAP header
-value in the response to signal to the receiver that the extension is being
-used.</p>
         <p>The Delete request message MUST be of the following form:</p>
         <example>
           <eg><kw>[Action]</kw>
@@ -849,12 +794,6 @@
           </gitem>
         </glist>
 
-        <p>
-         Specifications which define extensions for use in the original 
-         Delete request which control the format of the response MUST allow 
-         processing the Delete message without such extensions.
-        </p>
-
         <p> 
          Other components of the outline above are not further constrained 
          by this specification.
@@ -964,14 +903,7 @@
             </def>
           </gitem>
         </glist>
-        <p>Extensions specifications MAY also define extensions to the original
-    Create request, enabled by OPTIONAL SOAP headers, which constrain the nature
-    of the response, as discussed in remarks on the CreateResponse
-    below.Similarly, they may require headers which control the
-    interpretation of the wst:Create as part of the resource creation process.
-    </p>
-        <p>Such specifications MUST also allow processing the Create message without
-    such extensions. </p>
+
         <p>A Create request MUST be targeted at a resource factory capable of
     creating the desired new resource. This factory is distinct from the resource
     being created (which by definition does not exist prior to the successful
@@ -1036,21 +968,6 @@
                wst:CreateResponse element even in this case, however.
               </p>
 
-              <p>
-               Extension specifications MAY define extensions to the original
-               Create request, enabled by OPTIONAL header values, which 
-               specifically control the presence, absence, or format of the 
-               initial representation or other child elements in the 
-               CreateResponse. These headers MAY override the default 
-               behavior if they are marked with 
-               <code>s:mustUnderstand="true"</code>. In the absence of 
-               such OPTIONAL headers, the behavior MUST be as described in 
-               the previous paragraphs. Since the response may not be 
-               sent to the original sender, extension specifications should 
-               consider adding a corresponding SOAP header value in 
-               the response to signal to the receiver that the
-               extension is being used.
-              </p>
             </def>
           </gitem>
 
@@ -1668,6 +1585,13 @@
          <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=6648">6648</loc>
         </td>
        </tr>
+       <tr>
+        <td> 2009/04/20 </td>
+        <td> DD </td>
+        <td> Added resolution of issue 
+         <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=6730">6730</loc>
+        </td>
+       </tr>
       </tbody>
      </table>
     </div1>

Index: wst.html
===================================================================
RCS file: /w3ccvs/WWW/2002/ws/ra/edcopies/wst.html,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -d -r1.30 -r1.31
--- wst.html	21 Apr 2009 00:04:41 -0000	1.30
+++ wst.html	21 Apr 2009 00:40:40 -0000	1.31
@@ -226,20 +226,7 @@
                can be used for extensibility purposes.
               </p></dd></dl><p>A Get request MUST be targeted at the resource whose representation is
  desired as described in <a href="#Notations_and_Terminology"><b>2 Terminology and Notation</b></a> of
-this specification.</p><p>As per
-the SOAP processing model, other specifications may introduce various types
-of extensions to the semantics of this message which are enabled through
-headers tagged with <code>s:mustUnderstand="true"</code>. Such extensions
-may define how resource or subsets of it are to be retrieved or transformed
-prior to retrieval. Specifications which define such extensions MUST
-allow processing the basic Get request message without those
-extensions. Since the response may not be sent to the original sender,
-extension specifications should consider adding a corresponding SOAP header
-value in the response to signal to the receiver that the extension is being
-used.</p><p>Implementations may respond with a fault message using the standard fault
-codes defined in WS-Addressing (e.g., wsa:ActionNotSupported). Other
-components of the outline above are not further constrained by this
-specification.</p><p>If the resource accepts a Get request, it MUST reply with a response of
+this specification.</p><p>If the resource accepts a Get request, it MUST reply with a response of
 the following form:</p><div class="exampleOuter"><div class="exampleInner"><pre><b>[Action]</b>
   http://www.w3.org/2009/02/ws-tra/GetResponse
 
@@ -339,24 +326,9 @@
               </p></dd></dl><p>
          A Put request MUST be targeted at the resource whose representation is
          desired to be replaced, as described in 
-         <a href="#Notations_and_Terminology"><b>2 Terminology and Notation</b></a> of this specification. As
-         per the SOAP processing model, other specifications MAY 
-         introduce various types of extensions to this message which 
-         are enabled through headers tagged with 
-         <code>s:mustUnderstand="true"</code>. Such extensions may require
-         that a full or partial update should be accomplished using symbolic,
-         instruction-based, or other methodologies.
-        </p><p>
-         Extension specifications MAY also define extensions to the 
-         original Put request, enabled by OPTIONAL SOAP headers, which 
-         control the nature of the response, as discussed in remarks on 
-         the PutResponse below.
-        </p><p>
-         Specifications which define any of these extensions MUST allow 
-         processing the Put message without such extensions.
+         <a href="#Notations_and_Terminology"><b>2 Terminology and Notation</b></a> of this specification.
         </p><p>
-         In addition to the standard fault codes defined in WS-Addressing,
-         implementations MAY use the fault code wst:InvalidRepresentation 
+         Implementations MAY use the fault code wst:InvalidRepresentation 
          if the presented representation is invalid for the target resource. 
          See <a href="#Faults"><b>5 Faults</b></a>. Other components of the outline above are not 
          further constrained by this specification.
@@ -388,19 +360,6 @@
                return the current representation of the resource as the 
                initial child of the wst:PutResponse element even in this 
                case, however.
-              </p><p>
-               Extension specifications MAY define extensions to the original 
-               Put request, enabled by OPTIONAL header values, which 
-               specifically control the presence, absence, or format of the 
-               updated representation or other child elements in the 
-               PutResponse in order to optimize the response.  In the 
-               absence of such headers, the behavior MUST be as described
-               above. Specifications which define any of these extensions MUST
-               allow processing the Put message without such extensions. 
-               Since the response may not be sent to the original sender, 
-               extension specifications should consider adding a 
-               corresponding SOAP header value in the response to signal 
-               to the receiver that the extension is being used.
               </p></dd></dl><p>Other components of the outline above are not further constrained by this
 specification.</p><p>The following shows a sample SOAP envelope containing a Put request:</p><div class="exampleOuter"><div class="exampleInner"><pre>&lt;s:Envelope  
     xmlns:s="http://www.w3.org/2003/05/soap-envelope" 
@@ -455,13 +414,7 @@
   &lt;/s:Body/&gt;
 &lt;/s:Envelope&gt; </pre></div></div></div><div class="div2">
 <h3><a name="Delete" id="Delete"/>3.3 Delete</h3><p>This specification defines one Web service operation (Delete) for deleting
-a resource in its entirety.</p><p>Extension specifications MAY define extensions to the Delete request,
-enabled by OPTIONAL header values, which specifically control preconditions
-for the Delete to succeed and which may control the nature or format of the
-response. Since the response may not be sent to the original sender,
-extension specifications should consider adding a corresponding SOAP header
-value in the response to signal to the receiver that the extension is being
-used.</p><p>The Delete request message MUST be of the following form:</p><div class="exampleOuter"><div class="exampleInner"><pre><b>[Action]</b>
+a resource in its entirety.</p><p>The Delete request message MUST be of the following form:</p><div class="exampleOuter"><div class="exampleInner"><pre><b>[Action]</b>
   http://www.w3.org/2009/02/ws-tra/Delete
 
 <b>[Body]</b>
@@ -487,11 +440,7 @@
   &lt;/wst:DeleteResponse&gt;</pre></div></div><dl><dt class="label"><b>[Body]</b>/wst:DeleteResponse </dt><dd><p>
                This REQUIRED element MAY contain a child element that
                can be used for extensibility purposes.
-              </p></dd></dl><p>
-         Specifications which define extensions for use in the original 
-         Delete request which control the format of the response MUST allow 
-         processing the Delete message without such extensions.
-        </p><p> 
+              </p></dd></dl><p> 
          Other components of the outline above are not further constrained 
          by this specification.
         </p><p>The following shows a sample SOAP envelope containing a Delete
@@ -571,13 +520,7 @@
                If this element does not
                contain any children then the resource will be created
                using default values.
-              </p></dd></dl><p>Extensions specifications MAY also define extensions to the original
-    Create request, enabled by OPTIONAL SOAP headers, which constrain the nature
-    of the response, as discussed in remarks on the CreateResponse
-    below.Similarly, they may require headers which control the
-    interpretation of the wst:Create as part of the resource creation process.
-    </p><p>Such specifications MUST also allow processing the Create message without
-    such extensions. </p><p>A Create request MUST be targeted at a resource factory capable of
+              </p></dd></dl><p>A Create request MUST be targeted at a resource factory capable of
     creating the desired new resource. This factory is distinct from the resource
     being created (which by definition does not exist prior to the successful
     processing of the Create request message).</p><p>In addition to the standard fault codes defined in WS-Addressing,
@@ -624,20 +567,6 @@
                operations are performed). A service MAY return the current
                representation of the resource as the initial child of the 
                wst:CreateResponse element even in this case, however.
-              </p><p>
-               Extension specifications MAY define extensions to the original
-               Create request, enabled by OPTIONAL header values, which 
-               specifically control the presence, absence, or format of the 
-               initial representation or other child elements in the 
-               CreateResponse. These headers MAY override the default 
-               behavior if they are marked with 
-               <code>s:mustUnderstand="true"</code>. In the absence of 
-               such OPTIONAL headers, the behavior MUST be as described in 
-               the previous paragraphs. Since the response may not be 
-               sent to the original sender, extension specifications should 
-               consider adding a corresponding SOAP header value in 
-               the response to signal to the receiver that the
-               extension is being used.
               </p></dd><dt class="label"><b>[Body]</b>/wst:CreateResponse/wst:ResourceCreated </dt><dd><p>
                This required element MUST contain a resource reference for the
                newly created resource. This resource reference, represented 
@@ -1036,4 +965,5 @@
          <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=6641">6641</a></td></tr><tr><td> 2009/03/11 </td><td> DD </td><td> Added resolution of issue 
          <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=6425">6425</a></td></tr><tr><td> 2009/03/23 </td><td> DD </td><td> Added resolution of issue 
          <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=6666">6666</a></td></tr><tr><td> 2009/03/24 </td><td> DD </td><td> Added resolution of issue 
-         <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=6648">6648</a></td></tr></tbody></table></div></div></body></html>
\ No newline at end of file
+         <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=6648">6648</a></td></tr><tr><td> 2009/04/20 </td><td> DD </td><td> Added resolution of issue 
+         <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=6730">6730</a></td></tr></tbody></table></div></div></body></html>
\ No newline at end of file
Received on Tuesday, 21 April 2009 00:40:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:28 GMT