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

Folks,

A thought on the <wst:Representation/> issue. The idea of a blank  
representation is our corner case, so lets do that.

1) Define a <wst:BlankRepresentation/> element, which MUST always be  
empty.

2) The schema for our requests look something like this:

<Put>
    <xs:any>
    <xs:anyother>*
</Put>

-  On Put and Create the first element is always the representation/ 
instructions and the optional elements after that are always the  
extensions.

- The <wst:BlankRepresentation/>  element can be returned by Get to  
indicate the absence of any XML.

- The Implicit Get in Put & Create could do the same, although I would  
like to see the back of this implicit get.

Examples:

<Put>
    <dave:Stuff> ... </dave:stuff>
    <ram:ExtensionStuff type:"Cool"/>
</Put>

<Put>
    <wst:BlankRepresentation/>
    <ram:ExtensionStuff type:"Cool"/>
</Put>

This would fault.

<Put>
    <dave:Stuff> ... </dave:stuff>
    <wst:BlankRepresentation/>
    <ram:ExtensionStuff type:"Cool"/>
</Put>

Thoughts?

On 26 Jan 2010, at 23:29, Gilbert Pilz wrote:

> 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
> <wst-8180-8299-8302.zip>

Take care:

     Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
     Fujitsu Laboratories of Europe Limited
     Hayes Park Central
     Hayes End Road
     Hayes, Middlesex  UB4 8FE
     Reg. No. 4153469

     +44-7590-293439 (Mobile)






______________________________________________________________________
                                        
 Fujitsu Laboratories of Europe Limited
 Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
 Registered No. 4153469
 
 This e-mail and any attachments are for the sole use of addressee(s) and
 may contain information which is privileged and confidential. Unauthorised
 use or copying for disclosure is strictly prohibited. The fact that this
 e-mail has been scanned by Trendmicro Interscan and McAfee Groupshield does
 not guarantee that it has not been intercepted or amended nor that it is
 virus-free.