This specification intends to meet the following requirements:

This specification does not intend to meet the following requirements:

This section contains a complete example of a WS-RT "Get" operation. This example is meant for illustration only and does not represent normative behavior or content.

shows the XML representation of the example resource which will be accessed by the protocol operation. The example resource is a physical disk which has a number of logical volumes.

The protocol message for retrieving parts of the above resource representation is shown in . The response message of a WS-Transfer "Get" request message would return the entire representation of the resource, so this example illustrates a WS-RT "Get" request message augmented for extracting specific fragments of the representation:

In this example, the operation is a WS-Transfer "Get" as defined by the wsa:Action in line (09). The extended, fragment-aware Get behavior is indicated by the wsrt:ResourceTransfer header at line (11). The resource being accessed is referenced by the WS-Addressing endpoint reference, implied by the wsa:To element on line (07). WS-RT extensions for extracting fragments of the resource representation are in the wsrt:Get block on lines (15) through (27). For each targeted fragment the value to be selected is specified in the wsrt:Expression element.

The response to the "Get" message is illustrated in .

Note that the value of each resource fragment requested via a wsrt:Expression element is individually returned in a matching wsrt:Result element. This example uses the XPath Level 1 Dialect for the wsrt:Expression elements, one of which shows the use of the XPath text() NodeTest. The wsrt:Result for the third fragment contains only the serialized text value of that element (line (25)), rather than the XML element wrapper as in the other cases.

Some of the terminology defined in this specification is repeated from the WS-Transfer specification for convenience and is not meant to deviate from those definitions in any way.

The XML Namespace URI that MUST be used by implementations of this specification is:

lists XML namespaces that are used in this specification. The choice of any namespace prefix is arbitrary and not semantically significant.

The working group intends to update the value of the Web Services Transfer namespace URI each time a new version of this document is published until such time that the document reaches Candidate Recommendation status. Once it has reached Candidate Recommendation status, the working group intends to maintain the value of the Web Services Transfer namespace URI that was assigned in the Candidate Recommendation unless significant changes are made that impact the implementation or break post-CR implementations of the specification. Also see http://www.w3.org/2001/tag/doc/namespaceState.html and http://www.w3.org/2005/07/13-nsuri .

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 .

This specification uses the following syntax to define outlines for messages:

In addition to Message Information Header properties , this specification uses the following properties to define messages:

These properties bind to a SOAP Envelope as follows:

This specification defines Fault properties for each defined fault and defines SOAP bindings for each Fault property.

The elements defined in this specification MAY be extended at the points indicated by their outlines and schema. Implementations MAY add child elements and/or attributes at the indicated extension points but MUST NOT contradict the semantics of the parent and/or owner, respectively. If a receiver does not recognize an extension, the receiver SHOULD ignore that extension. Senders MAY indicate the presence of an extension that has to be understood through the use of a corresponding SOAP Header with a soap:mustUnderstand attribute with the value "1".

An implementation is not compliant with this specification if it fails to satisfy one or more of the MUST or REQUIRED level requirements defined herein. A SOAP Node MUST NOT use the XML namespace identifier for this specification (listed in ) within SOAP Envelopes unless it is compliant with this specification.

Normative text within this specification takes precedence over the XML Schema and WSDL descriptions, which in turn take precedence over outlines, which in turn take precedence over examples.

All messages defined by this specification MUST be sent to a Web service that is addressable by an EPR (see ).

Since an EPR refers to a resource as a whole, techniques which are used to reference or access parts of the resource representation are referred to as "fragment access" in that they access fragments of the XML representing the resource.

This specification defines an extensible mechanism for designating the expression syntax by which the fragment is identified or computed, and defines several such standard expression syntaxes or "dialects".

The dialects defined below are used to form an expression that can be evaluated with respect to the XML document that represents the resource. The de-referenced value of the expression is the part of the XML that is of interest. The expression may form a logical "pointer" to the fragment of XML that is of interest or, depending on the dialect, may form a query that can be applied to the XML document to produce an evaluated result. It is important to understand that these expression dialects simply identify the appropriate fragment of the resource representation and that the [Action] itself defines what will happen to the referenced fragment.

The definition of each dialect must clearly specify how the result of evaluating an expression against a resource representation is serialized to XML and should specify any dialect-specific behavior for operations that access the resource representation.

The WS-Transfer Get operation is used to retrieve an existing resource representation in its entirety. WS-ResourceTransfer extends the "Get" operation to retrieve fragments of an existing representation. A resource that can return its full representation MUST also support wst:Get to return the entire resource representation without using WS-ResourceTransfer extensions.

The [Body] of wsrt:Get contains an expression that identifies the fragment of interest.

The outline for wsrt:Get is:

The following describes additional constraints on the outline listed above:

If the resource accepts a wsrt:Get request and processes it successfully it MUST reply with a response of the following form:

The following describes additional constraints on the outline listed above:

An example Get message using the XPath Level 1 dialect and the expected GetResponse is shown in and the expected GetResource is shown in , for the resource whose XML representation is shown in above.

An example Get message that uses the QName dialect is shown in below.

The fragments of the resource representation are identified by the wsrt:Expression contents on lines (18) and (21). Notice that the d:Volume QName in the example resolves to three elements in the resource representation. The response to this "Get" message is illustrated in .

The value of each of the wsrt:Expression fragments in the request message is returned in a unique wsrt:Result wrapper in the response message. The order of the wsrt:Result elements in the response matches the order of the corresponding wsrt:Expression elements in the request. The result of getting the <d:Volume> fragment, for example, is shown on lines (18) - (37).

One final example of the Get operation, using the full XPath 1.0 dialect, is shown below in . This illustrates the use of a query expression to return the computed result of the quantity of d:Volume elements that have a capacity greater than 20000000000. For the sake of brevity, only the message body is shown.

The expression on line (05), when applied to the resource representation in , evaluates to a result of "2".

The result of the query expression is a number which is converted to an xs:double and returned as the value of the wsrt:Result element shown on line (03).

The WS-Transfer "Put" operation is used to update an existing resource representation by providing a replacement XML representation. WS-ResourceTransfer extends the "Put" operation to update an existing resource representation by providing fragments of the XML representation. A resource that can update its full representation MUST also support wst:Put to update the entire resource representation without using WS- ResourceTransfer extensions.

The extended outline for the "Put" operation is:

The following describes additional constraints on the outline listed above:

If a resource encounters a failure while processing the fragments in a Put request, it MUST generate a PutFault. The resource SHOULD ensure that its representation is unchanged from prior to the request, although atomic behavior is not required of resource implementations. The resource SHOULD include a wsrt:SideAffects element in the fault detail to indicate whether any changes occurred.

If the resource accepts a Put request and performs the requested update, it MUST reply with a response of the following form:

The following describes additional constraints on the outline listed above:

An example Put message using the XPath Level 1 dialect is shown in . For brevity only the message body is shown.

Line (04) indicates that a fragment should be removed and is targeted at the 1^st Volume element, identified by the wsrt:Expression contents on line (05). Line (09) indicates that a fragment should be inserted into the representation that results from applying the first fragment update. The insertion location is identified by the wsrt:Expression contents on line (11), i.e. immediately before the second Volume element. Lines (13) - (18) show the content of the new Volume which is to be inserted. The updated resource representation is illustrated in .

Lines (12) - (17) show the result of the Put@Insert operation. Drive C was removed and X was inserted at position 2 in between drive D and E since the expression targeted the 2^nd Volume element after the removal of C.

An example Put message using the QName dialect is shown in . For brevity only the message body is shown.

Line (04) again indicates that the fragment needs to be updated (i.e logically removed and then replaced). The target fragment of the resource is the set of d:Volume elements, identified by the wsrt:Expression contents on line (06). Lines (08) - (19) show the new value for this set of elements to use to replace the old set.

Lines (21) - (32) indicates that a fragment should be inserted into the representation that results from applying the first fragment update. Lines (25) - (31) show the content of the new Volume which is added at the end.

The updated resource representation is illustrated in .

Lines (06) - (17) show the result of the Put@Modify operation. Drives C, D and E are replaced by drives D and F. Effectively, drives C and E are removed and drive F is inserted. Lines (18) - (23) show the result of the Put@Insert operation. The Volume element for drive X is added at the end of the array of Volumes.

The WS-Transfer "Create" operation is used for creating a resource via an initial representation. The resource factory that receives a Create request will allocate a new resource that is initialized from the presented representation. The new resource will be assigned a factory-service-determined endpoint reference that is returned in the response message. In many cases, the information required to create a resource may markedly differ from the initial representation (the value as realized by a subsequent "Get" operation), and supplying the initial representation is not viable.

WS-ResourceTransfer extends the "Create" operation to create a resource from zero or more specified fragments of the XML representation. WS-ResourceTransfer further extends the "Create" operation such that any resource metadata MAY be created as part of the creation of the resource.

The extended outline for the "Create" operation is:

The following describes additional constraints on the outline listed above:

If the resource factory accepts a Create request, it MUST reply with a response of the following form:

The following describes additional constraints on the outline listed above:

If the request Body contained a wsrt:Create element then the new representation MUST be omitted in the response. Otherwise the response MUST be as described in WS-Transfer.

An example Create message using the QName dialect is shown in . For brevity only the message body is shown.

Line (09) indicates that the resource, once created, is scheduled for destruction at the specific time. Messages sent to the EPR returned in the CreateResponse, after this time, will fault. Line (23) indicates that resource is created with a specific value or set of values for the <d:Volume> property. Lines (25) - (36) specify the set of values of the <d:Volume> property. The response to this "Create" message is illustrated in .

Lines (02) - (07) show the EPR to the disk resource that is returned in the response message.

This fault is sent in response to a message that is targeted at a resource that cannot be found and is deemed not to exist. This may be because the resource was never created or because the resource has been destroyed - there is no distinction between these cases.

The SOAP bindings for this fault are defined in .

The resource is unable to process the message at this time due to some transient issue. The endpoint MAY optionally include a wsa:RetryAfter parameter in the detail. The source should not retransmit the message until this duration has passed.

The SOAP bindings for this fault are defined in .

This fault is generated by a resource to indicate that it was unable to process a message due to concurrent access. A requester might choose to handle this condition by retrying the operation that caused it.

This fault is generated by a resource to indicate that the expression dialect used to identify a resource fragment is not supported by the resource for the current operation. The fault detail SHOULD contain the Dialect values that the resource does support for the operation.

This fault is sent by a resource if a <wsrt:Expression> element has an syntax that is invalid according to the definition of the expression dialect. If the expression syntax is not valid with respect to the dialect then a resource SHOULD specify a fault detail of "InvalidExpressionSyntax", indicating which expression this detail applies to. If the expression is not valid for the resource type then the resource SHOULD specify a fault detail of "InvalidExpressionValue", indicating which expression this detail applies to.

This fault is generated by a resource if it is unable to process a valid Get message.

This fault is generated by a resource if the result of processing a Put message would cause the resource representation to become invalid. The fault detail MAY include the wsrt:Fragment element in the Put message that caused this fault to be generated.

This fault is generated by a resource if a "Put" message specifies the "http://www.w3.org/2009/02/ws-rst/Insert" mode and identifies a non-repeated fragment element (maxOccurrs = 1) that already exists. The fault detail MAY include the wsrt:Fragment that failed to be processed.

This fault is generated by a resource if it is unable to process a valid Put message. The fault detail MAY include the wsrt:Fragment that failed to be processed.

The fault detail SHOULD include a wsrt:SideAffects element in the fault detail to indicate whether any changes occurred. A value of "true" indicates some changes occurred; a value of "false" indicates no changes occurred. Absence of the element indicates that changes may have occurred.

This fault is generated by a resource if a "Put" message specifies a mode that is not supported by the resource.

This fault is generated by a resource if it is unable to process a valid Create message. The fault detail MAY include the wsrt:Fragment that failed to be processed.

This fault is generated by a resource factory if a "Create" message contains a wsmex:Dialect that is not supported or if the resource metadata contains values that are not supported for the resource.

This fault is generated by a resource if a request message exceeds the limit of wsrt:Expression or wsrt:Fragment elements supported for the dialect. The fault detail MUST contain the maximum number of wsrt:Expression or wsrt:Fragment elements supported for the dialect.

This fault is generated by a resource if a Put request specifying a Mode "http://www.w3.org/2009/02/ws-rst/Remove" contains a wsrt:Value element or if a Put request specifying a Mode "http://www.w3.org/2009/02/ws-rst/Insert" or "http://www.w3.org/2009/02/ws-rst/Modify" does not contain a wsrt:Value element.