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
The more I'm around some people, the more I like my dog.



Ram Jeyaraman <Ram.Jeyaraman@microsoft.com> 
01/14/2011 02:37 PM

To
Doug Davis/Raleigh/IBM@IBMUS
cc
"Bob Freund (bob.freund@hitachisoftware.com)" 
<bob.freund@hitachisoftware.com>, "public-ws-resource-access@w3.org" 
<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] 
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
The more I'm around some people, the more I like my dog. 


Ram Jeyaraman <Ram.Jeyaraman@microsoft.com> 
Sent by: public-ws-resource-access-request@w3.org 
01/13/2011 07:11 PM 


To
"Bob Freund (bob.freund@hitachisoftware.com)" <
bob.freund@hitachisoftware.com> 
cc
"public-ws-resource-access@w3.org" <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.