RE: WS-Transfer empty resource feature at risk

When we discussed this during the meeting, it seemed like just a matter of schema testing. But on further investigation, it does not appear to be so. Here is why.

The issue at hand is whether a resource is required to support null representation / state. Currently, WS-Transfer expects a service to do the following:

1.        Support wst:Create with a wst:Representation that is empty.

a.       This creates a resource with a null representation

2.       Support wst:Put with a wst:Representaton that is empty.

a.       This nulls out the representation of a resource.

It is conceivable that an implementation may not support the notion of a resource with null representation for valid reasons. The schema of the resource would not allow for null state / representation. That is, the implementation assumes that if there is a resource it always has concrete representation, otherwise, the resource is non-existent; hence, there is no null state / representation.

WS-Transfer states:


Ø  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.

When such an implementation receives a wst:Create or a wst:Put request as per the current specification, it would not be able to support the null case (since the resource schema does not allow null states); that is, the implementation cannot support wst:Create with a null representation, nor can it support a the ability to null out a resource (wst:Put with a null representation), and hence will throw a wst:InvalidRepresentation fault.

Further, such an implementation cannot conform to the following requirements in the specification highlighted below:

1. [Body]/wst:Create/wst:Representation
This OPTIONAL element acts as a container for the full representation of the resource. If this element is not present the resource MUST be created using default values (equivalent to a null constructor). This element MAY have no children, in which case the resource MUST be created with an empty representation (equivalent to an empty constructor).

2. [Body]/wst:Put/wst:Representation
This OPTIONAL element acts as a container for the full representation of the resource. This element MUST be present if the Dialect attribute is absent. This element MAY have no children. This case MUST be interpreted as a request to remove the resource's representation, not the resource itself.
Since such an implementation cannot demonstrate conformity to the requirements highlighted above, it cannot be counted as a valid implementation of these requirements.

A couple of possible options we can pursue:

1.        Mark the requirements relating to null representation state as at risk.

2.       Remove or relax the requirements so it does not come in the way of conformance.

a.       For example, the requirement could be modified to indicate that *if* a resource supports null values as defined, it may choose to exhibit the stated behavior.

Thanks.

From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Thursday, January 13, 2011 5:16 PM
To: Ram Jeyaraman
Cc: Bob Freund (bob.freund@hitachisoftware.com); public-ws-resource-access@w3.org
Subject: Re: WS-Transfer empty resource feature at risk


Ram,
  during the meeting we agreed that his was akin to more like schema testing which isn't really testing the transfer spec itself - so we remove that as a stand-alone feature.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com<mailto:dug@us.ibm.com>
The more I'm around some people, the more I like my dog.

Ram Jeyaraman <Ram.Jeyaraman@microsoft.com<mailto:Ram.Jeyaraman@microsoft.com>>
Sent by: public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org>

01/13/2011 07:11 PM

To

"Bob Freund (bob.freund@hitachisoftware.com<mailto:bob.freund@hitachisoftware.com>)" <bob.freund@hitachisoftware.com<mailto:bob.freund@hitachisoftware.com>>

cc

"public-ws-resource-access@w3.org<mailto:public-ws-resource-access@w3.org>" <public-ws-resource-access@w3.org<mailto:public-ws-resource-access@w3.org>>

Subject

WS-Transfer empty resource feature at risk







Hi Bob,

We touched upon this during our previous meeting - WS-Transfer and WS-Fragment have this notion of an empty representation.

[Body]/wst:Create/wst:Representation
This OPTIONAL element acts as a container for the full representation of the resource. If this element is not present the resource MUST be created using default values (equivalent to a null constructor). This element MAY have no children, in which case the resource MUST be created with an empty representation (equivalent to an empty constructor).
During interoperation testing, Microsoft does not plan to test the empty representation case. That would leave that feature with likely just one implementation.

Hence, I suggest marking the empty representation case as a feature at risk during CR.

Thanks.