Re: WS-Transfer empty resource feature at risk

the decision to go CR gas already been done.

On Jan 17, 2011, at 12:55 PM, Ram Jeyaraman wrote:

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