Re: combined proposal for issues 8180, 8299, and 8302

I don't think "we" (the WS-RA WG) need to determine the semantics of 
these cases at all; that is a job for the resource manager.

- gp

On 1/27/2010 7:20 AM, Ram Jeyaraman wrote:
>
> Gil, thanks for the proposal.
>
> Thinking about the basic model, I wonder about what does it mean to 
> null out a resource.
>
> Here are some possible representational states of a resource:
>
> 1. Has non-empty representation – that is , “a”.
>
> a. Resource exists
>
> 2. Has empty representation – that is, “”.
>
> a. Resource exists
>
> 3. Has no representation – that is, null.
>
> a. Does this mean that the resource does not exist or it exists in a 
> default form (representation)?
>
> Now, let us explore the semantics of using the possible 
> representational forms within the various Transfer operations.
>
>  
>
> *Non-empty representation (“a”)*
>
>  
>
> *Empty representation (“”)*
>
>  
>
> *Null representation (null) [assuming resource does not exist]*
>
>  
>
> *Null representation (null) [assuming resource exists in default form]*
>
> *Create*
>
>  
>
> Creates resource with representation “a”
>
>  
>
> Creates resource with representation “”
>
>  
>
> What does it mean to create a resource that is null or non-existent?
>
>  
>
> Creates resource with a default representation.
>
> *CreateResponse*
>
>  
>
> MAY return representation “a”
>
>  
>
> MAY return representation “”
>
>  
>
> What does it mean to return a null or non-existent resource?
>
>  
>
> MAY return default representation. What would this representation look 
> like? <wst:Resource/>? Or would it have some default values?
>
> *Put*
>
>  
>
> Updates resource with representation “a”
>
>  
>
> Updates resource with representation “”
>
>  
>
> What does this mean to null out or make a resource non-existent? Isn’t 
> this same as deletion?
>
>  
>
> Updates resource with default representation
>
> *PutResponse*
>
>  
>
> MAY return representation “a”
>
>  
>
> MAY return representation “”
>
>  
>
> What does it mean to return a null or non-existent resource?
>
>  
>
> MAY return default representation. What would this representation look 
> like? <wst:Resource/>? Or would it have some default values?
>
> *Get*
>
>  
>
> N/A
>
>  
>
> N/A
>
>  
>
> How is it even possible to reach a non-existent resource?
>
>  
>
> N/A
>
> *GetResponse*
>
>  
>
> Returns representation “a”
>
>  
>
> Returns representation “”
>
>  
>
> What does it mean to return a null or non-existent resource?
>
>  
>
> Returns default representation. would this representation look like? 
> <wst:Resource/>? Or would it have some default values?
>
> *Delete*
>
>  
>
> N/A
>
>  
>
> N/A
>
>  
>
> N/A
>
>  
>
> N/A
>
> *DeleteResponse*
>
>  
>
> N/A
>
>  
>
> N/A
>
>  
>
> N/A
>
>  
>
> N/A
>
> We need to decide on the semantics of the null representation. Does it 
> mean that the resource does not exist or it exist with some default 
> representation?
>
> Thanks.
>
> *From:* public-ws-resource-access-request@w3.org 
> [mailto:public-ws-resource-access-request@w3.org] *On Behalf Of 
> *Gilbert Pilz
> *Sent:* Tuesday, January 26, 2010 11:30 PM
> *To:* public-ws-resource-access@w3.org
> *Subject:* combined proposal for issues 8180, 8299, and 8302
>
> To summarize the positions on the basic issues:
>
> 8180:
>
> Yes, resource representations can be "empty", i.e. "have no value". 
> Empty resources are created by supplying a <wst:Representation/> in 
> Create. The existence of an empty resource is indicated by a Get that 
> returns a <wst:Representation/>. Resources can be "made empty (i.e. 
> have their representation removed) by Put-ing a <wst:Representation/>.
>
> 8299:
>
> The ambiguity between representation and extensions has been removed 
> by the introduction of the wst:Representation element. The XML element 
> inside a wst:Representation is the representation. Anything outside 
> the wst:Representation element (and in a different namespace that 
> WS-T) is an extension. This is described without complicated language 
> on the optionality of representation etc.
>
> 8302:
>
> I believe this is significantly clearer and more straightforward than 
> previous versions. The use of the "implicit Get" operation is 
> described in straightforward way that allows for it to be used in a 
> multitude of situations but does not require services to perform 
> onerous tasks such as transmitting very large messages in response to 
> very large requests.
>
> - gp
>