- 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
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><s:Envelope
xmlns:s="http://www.w3.org/2003/05/soap-envelope"
@@ -455,13 +414,7 @@
</s:Body/>
</s:Envelope> </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 @@
</wst:DeleteResponse></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 UTC