- From: Doug Davis via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 10 Feb 2010 01:02:59 +0000
- To: public-ws-resource-access-notifications@w3.org
Update of /w3ccvs/WWW/2002/ws/ra/edcopies
In directory hutz:/tmp/cvs-serv26247
Modified Files:
wst.html wst.xml
Log Message:
8298
Index: wst.xml
===================================================================
RCS file: /w3ccvs/WWW/2002/ws/ra/edcopies/wst.xml,v
retrieving revision 1.103
retrieving revision 1.104
diff -u -d -r1.103 -r1.104
--- wst.xml 10 Feb 2010 00:49:45 -0000 1.103
+++ wst.xml 10 Feb 2010 01:02:57 -0000 1.104
@@ -82,30 +82,42 @@
<body>
<div1 id="intro">
<head>Introduction</head>
- <p>This specification defines a mechanism for acquiring XML-based
- representations of entities using the Web service infrastructure. It defines
- two types of entities:</p>
+ <p>
+ This specification defines a mechanism for acquiring XML-based
+ representations of entities using the Web service infrastructure.
+ It defines two types of entities:
+ </p>
+
<ulist>
<item>
- <p>Resources, which are entities addressable by an endpoint reference that
- provide an XML representation</p>
+ <p>
+ Resources, which are entities addressable by an endpoint
+ reference that provide an XML representation
+ </p>
</item>
<item>
<p>Resource factories, which are Web services that can create new
resources</p>
</item>
</ulist>
- <p>Specifically, it defines two operations for sending and receiving the
- representation of a given resource and two operations for creating and
- deleting a resource and its corresponding representation.</p>
- <p>Note that the state maintenance of a resource is at most
- subject to the "best efforts" of the hosting server. When a client receives
- the server's acceptance of a request to create or update a resource, it can
- reasonably expect that the resource now exists at the confirmed location and
- with the confirmed representation, but this is not a guarantee, even in the
- absence of any third parties. The server MAY change the representation of a
- resource, MAY remove a resource entirely, or MAY bring back a resource that
- was deleted.</p>
+
+ <p>
+ Specifically, it defines two operations for sending and receiving the
+ representation of a given resource and two operations for creating and
+ deleting a resource and its corresponding representation.
+ </p>
+
+ <p>
+ Note that the state maintenance of a resource is at most
+ subject to the "best efforts" of the hosting server. When a client
+ receives the server's acceptance of a request to create or update a
+ resource, it can reasonably expect that the resource now exists at
+ the confirmed location and with the confirmed representation, but this
+ is not a guarantee, even in the absence of any third parties. The
+ server MAY change the representation of a resource, MAY remove a
+ resource entirely, or MAY bring back a resource that was deleted.
+ </p>
+
<p>
For instance, the server might store resource state information on a
disk drive. If that drive crashes and the server recovers state
@@ -114,13 +126,13 @@
</p>
<p>
- A server MAY have other operational processes that change resource state
- information. For example, a server could purge resources that have not
- been accessed for some period of time.
+ A server might have other operational processes that change resource
+ state information. For example, a server could purge resources that
+ have not been accessed for some period of time.
</p>
<p>
- In addition to this, there MAY be application or process specific
+ In addition to this, there might be application or process specific
reasons for a server to augment or transform the representation
provided by an update or create operation. For example, the server
might populate the optional properties of a newly created resource
@@ -132,19 +144,25 @@
simultaneously accessing, creating, and updating the same resources.
</p>
- <p>In essence, the confirmation by a service of having processed a request to
- create, modify, or delete a resource implies a commitment only at the instant
- that the confirmation was generated. While the usual case is that
- resources are long-lived and stable, there are no guarantees, and clients
- are advised to code defensively.</p>
- <p>There is no requirement for uniformity in resource representations between
- the messages defined in this specification. For example, the
- representations used by Create or Put can differ from the representation
- returned by Get, depending on the semantic requirements of the service.
- Additionally, there is no requirement that the resource content is fixed for
- any given endpoint reference. The resource content can vary based on
- environmental factors, such as the security context, time of day,
- configuration, or the dynamic state of the service.</p>
+ <p>
+ In essence, the confirmation by a service of having processed a
+ request to create, modify, or delete a resource implies a commitment
+ only at the instant that the confirmation was generated. While the
+ usual case is that resources are long-lived and stable, there are no
+ guarantees, and clients are advised to code defensively.
+ </p>
+
+ <p>
+ There is no requirement for uniformity in resource representations
+ between the messages defined in this specification. For example, the
+ representations used by Create or Put can differ from the representation
+ returned by Get, depending on the semantic requirements of the service.
+ Additionally, there is no requirement that the resource content is
+ fixed for any given endpoint reference. The resource content can vary
+ based on environmental factors, such as the security context, time
+ of day, configuration, or the dynamic state of the service.
+ </p>
+
<div2 id="reqs">
<head>Requirements</head>
<p>This specification intends to meet the following requirements:</p>
@@ -805,13 +823,12 @@
</p>
<p>
- If an implementation that performs schema validation on a presented
- representation detects that the presented representation is invalid
- for the target resource, then the implementation MUST generate
+ The replacement representation could be considered to be invalid if
+ it does not conform to the schema(s) for the target resource or
+ otherwise violates some cardinality or type constraint.
+ If an implementation detects that the presented representation is
+ invalid for the target resource, then the implementation MUST generate
a wst:InvalidRepresentation fault.
- The replacement representation could be considered to be invalid if it
- does not conform to the schema(s) for the target resource or otherwise
- violates some cardinality or type constraint.
</p>
<p>
@@ -863,8 +880,8 @@
use as an optimization to save the client the overhead of
having to perform a subsequent Get operation. A service
MAY include this element to return the current
- representatin of the resource. This element MAY have no children
- in cases where there is no resource representation.
+ representation of the resource. This element MAY have no
+ children in cases where there is no resource representation.
</p>
</def>
@@ -968,8 +985,7 @@
<def>
<p>
This is a REQUIRED element that has no defined child element
- content. However, it MAY include child element content as
- defined by an extension(s).
+ content.
</p>
</def>
</gitem>
@@ -1642,7 +1658,7 @@
WS-MetadataExchange <bibref ref="MEX"/> Section 9.
This WS-Transfer WSDL can be annotated to indicate any endpoint
specific metadata that might be needed by clients interacting with
- this service. For example, the WSDL MAY have policy assertions
+ this service. For example, the WSDL might have policy assertions
that indicate a particular security mechanism used to protect
the WS-Transfer operations supported by this endpoint.
</p>
@@ -2764,6 +2780,13 @@
<loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=8160">8160</loc>
</td>
</tr>
+ <tr>
+ <td> 2010/02/09 </td>
+ <td> DD </td>
+ <td> Added resolution of issue
+ <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=8298">8298</loc>
+ </td>
+ </tr>
</tbody>
</table>
</div1>
Index: wst.html
===================================================================
RCS file: /w3ccvs/WWW/2002/ws/ra/edcopies/wst.html,v
retrieving revision 1.105
retrieving revision 1.106
diff -u -d -r1.105 -r1.106
--- wst.html 10 Feb 2010 00:49:39 -0000 1.105
+++ wst.html 10 Feb 2010 01:02:57 -0000 1.106
@@ -70,30 +70,38 @@
B <a href="#WSDL">WSDL</a><br/>
C <a href="#changelog">Change Log</a><br/>
</p></div><hr/><div class="body"><div class="div1">
-<h2><a name="intro" id="intro"/>1 Introduction</h2><p>This specification defines a mechanism for acquiring XML-based
- representations of entities using the Web service infrastructure. It defines
- two types of entities:</p><ul><li><p>Resources, which are entities addressable by an endpoint reference that
- provide an XML representation</p></li><li><p>Resource factories, which are Web services that can create new
- resources</p></li></ul><p>Specifically, it defines two operations for sending and receiving the
- representation of a given resource and two operations for creating and
- deleting a resource and its corresponding representation.</p><p>Note that the state maintenance of a resource is at most
- subject to the "best efforts" of the hosting server. When a client receives
- the server's acceptance of a request to create or update a resource, it can
- reasonably expect that the resource now exists at the confirmed location and
- with the confirmed representation, but this is not a guarantee, even in the
- absence of any third parties. The server MAY change the representation of a
- resource, MAY remove a resource entirely, or MAY bring back a resource that
- was deleted.</p><p>
+<h2><a name="intro" id="intro"/>1 Introduction</h2><p>
+ This specification defines a mechanism for acquiring XML-based
+ representations of entities using the Web service infrastructure.
+ It defines two types of entities:
+ </p><ul><li><p>
+ Resources, which are entities addressable by an endpoint
+ reference that provide an XML representation
+ </p></li><li><p>Resource factories, which are Web services that can create new
+ resources</p></li></ul><p>
+ Specifically, it defines two operations for sending and receiving the
+ representation of a given resource and two operations for creating and
+ deleting a resource and its corresponding representation.
+ </p><p>
+ Note that the state maintenance of a resource is at most
+ subject to the "best efforts" of the hosting server. When a client
+ receives the server's acceptance of a request to create or update a
+ resource, it can reasonably expect that the resource now exists at
+ the confirmed location and with the confirmed representation, but this
+ is not a guarantee, even in the absence of any third parties. The
+ server MAY change the representation of a resource, MAY remove a
+ resource entirely, or MAY bring back a resource that was deleted.
+ </p><p>
For instance, the server might store resource state information on a
disk drive. If that drive crashes and the server recovers state
information from a backup tape, changes that occurred after the
backup was made will be lost.
</p><p>
- A server MAY have other operational processes that change resource state
- information. For example, a server could purge resources that have not
- been accessed for some period of time.
+ A server might have other operational processes that change resource
+ state information. For example, a server could purge resources that
+ have not been accessed for some period of time.
</p><p>
- In addition to this, there MAY be application or process specific
+ In addition to this, there might be application or process specific
reasons for a server to augment or transform the representation
provided by an update or create operation. For example, the server
might populate the optional properties of a newly created resource
@@ -101,18 +109,22 @@
</p><p>
Finally all clients need to be aware that there might be other clients
simultaneously accessing, creating, and updating the same resources.
- </p><p>In essence, the confirmation by a service of having processed a request to
- create, modify, or delete a resource implies a commitment only at the instant
- that the confirmation was generated. While the usual case is that
- resources are long-lived and stable, there are no guarantees, and clients
- are advised to code defensively.</p><p>There is no requirement for uniformity in resource representations between
- the messages defined in this specification. For example, the
- representations used by Create or Put can differ from the representation
- returned by Get, depending on the semantic requirements of the service.
- Additionally, there is no requirement that the resource content is fixed for
- any given endpoint reference. The resource content can vary based on
- environmental factors, such as the security context, time of day,
- configuration, or the dynamic state of the service.</p><div class="div2">
+ </p><p>
+ In essence, the confirmation by a service of having processed a
+ request to create, modify, or delete a resource implies a commitment
+ only at the instant that the confirmation was generated. While the
+ usual case is that resources are long-lived and stable, there are no
+ guarantees, and clients are advised to code defensively.
+ </p><p>
+ There is no requirement for uniformity in resource representations
+ between the messages defined in this specification. For example, the
+ representations used by Create or Put can differ from the representation
+ returned by Get, depending on the semantic requirements of the service.
+ Additionally, there is no requirement that the resource content is
+ fixed for any given endpoint reference. The resource content can vary
+ based on environmental factors, such as the security context, time
+ of day, configuration, or the dynamic state of the service.
+ </p><div class="div2">
<h3><a name="reqs" id="reqs"/>1.1 Requirements</h3><p>This specification intends to meet the following requirements:</p><ul><li><p>Provide a SOAP-based protocol for managing resources and their
representations.
</p></li><li><p>Minimize additional mechanism beyond the current Web Services
@@ -454,13 +466,12 @@
desired to be updated, as described in
<a href="#Notations_and_Terminology"><b>2 Terminology and Notation</b></a> of this specification.
</p><p>
- If an implementation that performs schema validation on a presented
- representation detects that the presented representation is invalid
- for the target resource, then the implementation MUST generate
+ The replacement representation could be considered to be invalid if
+ it does not conform to the schema(s) for the target resource or
+ otherwise violates some cardinality or type constraint.
+ If an implementation detects that the presented representation is
+ invalid for the target resource, then the implementation MUST generate
a wst:InvalidRepresentation fault.
- The replacement representation could be considered to be invalid if it
- does not conform to the schema(s) for the target resource or otherwise
- violates some cardinality or type constraint.
</p><p>
The replacement representation could contain within it element or
attribute values that are different than their corresponding values in
@@ -495,8 +506,8 @@
use as an optimization to save the client the overhead of
having to perform a subsequent Get operation. A service
MAY include this element to return the current
- representatin of the resource. This element MAY have no children
- in cases where there is no resource representation.
+ representation of the resource. This element MAY have no
+ children in cases where there is no resource representation.
</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"
@@ -571,8 +582,7 @@
outline listed above:
</p><dl><dt class="label"><b>[Body]</b>/wst:Delete </dt><dd><p>
This is a REQUIRED element that has no defined child element
- content. However, it MAY include child element content as
- defined by an extension(s).
+ content.
</p></dd><dt class="label"><b>[Body]</b>/wst:Delete@Dialect </dt><dd><p>
When this OPTIONAL attribute is present it contains a IRI that
refers to additional information for the service on how to
@@ -943,7 +953,7 @@
WS-MetadataExchange <a href="#MEX">[WS-MetadataExchange]</a> Section 9.
This WS-Transfer WSDL can be annotated to indicate any endpoint
specific metadata that might be needed by clients interacting with
- this service. For example, the WSDL MAY have policy assertions
+ this service. For example, the WSDL might have policy assertions
that indicate a particular security mechanism used to protect
the WS-Transfer operations supported by this endpoint.
</p><div class="div2">
@@ -1499,4 +1509,5 @@
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=8302">8302</a>,
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=8180">8180</a>,
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=8299">8299</a></td></tr><tr><td> 2010/02/09 </td><td> DD </td><td> Added resolution of issue
- <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=8160">8160</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=8160">8160</a></td></tr><tr><td> 2010/02/09 </td><td> DD </td><td> Added resolution of issue
+ <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=8298">8298</a></td></tr></tbody></table></div></div></body></html>
\ No newline at end of file
Received on Wednesday, 10 February 2010 01:03:01 UTC