RE: WS-Transfer empty resource feature at risk

Yes, that sounds good. I suggest resolving this issue before production of the Candidate Recommendation draft. Thanks.

From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Friday, January 14, 2011 12:02 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,
  I see your concern now, and this may be a case of us being too close to the text at the time and missing the bigger picture.  I don't believe it was ever the intent for null resources to be required.  So your #2 is the right way to go.
  I think we originally assumed that the text you quoted about the new representation not matching the xsd generating the invalidRepresentation fault was supposed to be applied for Put and Create regardless of whether we're dealing will null resources or not.  Meaning, the service was supposed to take the incoming XML (full or empty), check it against the allowable schema(s) and if it matched then update/create the resource.  The problem is that the text (for both null and non-null cases) is split into two.  Meaning, it talks about updating/creating the resource from the incoming XML, and then in a separate paragraph it talks about schema validation.  These really should be merged. So I think a bit of clean-up is required for both cases.  I'll open an issue for this - not sure of the right text yet but I'll work on it....

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

01/14/2011 02:37 PM

To

Doug Davis/Raleigh/IBM@IBMUS

cc

"Bob Freund (bob.freund@hitachisoftware.com<mailto:bob.freund@hitachisoftware.com>)" <bob.freund@hitachisoftware.com<mailto:bob.freund@hitachisoftware.com>>, "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

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]<mailto:[mailto:dug@us.ibm.com]>
Sent: Thursday, January 13, 2011 5:16 PM
To: Ram Jeyaraman
Cc: Bob Freund (bob.freund@hitachisoftware.com<mailto:bob.freund@hitachisoftware.com>); public-ws-resource-access@w3.org<mailto: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.