Re: issue 6398: updated proposal - HTTP Linkage

And...
If we really got serious about the http alignment, then we would have  
to do something about those pesky eprs...
Query strings anyone? A WG note on mapping refPs to a text string  
perhaps?
-bob

On Feb 11, 2009, at 7:39 AM, Christopher B Ferris wrote:

> Geoff,
>
> The concerns we have, have _nothing_ to do with dispatching. The  
> issue w/r/t the wrapper is so that a WSDL description
> can be written for an unspecified type in the SOAP body.
>
> In the current WS-T, the WSDL violates the WS-I BP (no matter which  
> version) because it has a message part that has a @type associated
> with an operation intended for a doc-literal binding. That is  
> verboten.
>
> Per WS-I BP 1.1:
> R2204 A document-literal binding in a DESCRIPTION MUST refer, in  
> each of its soapbind:body element(s), only to wsdl:part element(s)  
> that have been defined using the element attribute.
> The purpose of the wrapper is to allow definition of an endpoint  
> that does not specify the  element content of the resource that is  
> returned (which is
> aligned with HTTP). If the specification were to require that all  
> transfer endpoints be described such that ONLY a single, specified  
> GED could be returned, well, I suppose that would work too, but  
> would be sub-optimal from our perspective since it is likely that  
> there will be endpoints that do not wish  specify the element  
> content of the resource that is returned.
>
> While there may be little value of the wrapper from your  
> perspective, there is from ours. Our tooling has been designed to  
> conform with the decisions
> made in the context of the WS- profiles. If you are intent in  
> preserving alignment of WS-T with HTTP, then WS-T needs to support  
> the REST uniform
> interface constraint that informed the design of HTTP. To do this,  
> the description of the interface (if it is to be conformant with the  
> WS-I profiles) must
> be designed such that there is a (single, defined) element  
> definition bound to the response.
>
> Cheers,
>
> Christopher Ferris
> IBM Distinguished Engineer, CTO Industry Standards
> IBM Software Group, Standards Strategy
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
> phone: +1 508 234 2986
>
>
> From:	Geoff Bullen <Geoff.Bullen@microsoft.com>
> To:	Doug Davis/Raleigh/IBM@IBMUS
> Cc:	Gilbert Pilz <gilbert.pilz@oracle.com>, "public-ws-resource-access@w3.org 
> " <public-ws-resource-access@w3.org>
> Date:	02/10/2009 03:15 PM
> Subject:	RE: issue 6398: updated proposal - HTTP Linkage
> Sent by:	public-ws-resource-access-request@w3.org
>
>
>
>
> Doug,
> Can we up-level a bit for a moment here.
>
> From what we understand, the WS-Transfer protocol was originally  
> designed to be aligned with HTTP, and currently still is.  You can  
> even see this in the names: Web Service Transfer Protocol –  
> Hypertext Transfer Protocol.  Basically, Transfer was designed to be  
> HTTP over SOAP over any SOAP binding.  This alignment with HTTP can  
> also be seen in the use of the same verbs and the separation of verb  
> and message body.  Currently the verbs are defined as wsa actions in  
> the soap header and the message body used in Transfer is delineated  
> by <soap:body>.  Note that <soap:body> is used for all messages and  
> carries no message specific meaning or semantics.
>
> If we now look at the current proposal:
> Firstly, we note that there appears to be little real value to these  
> wrappers, in that they add no semantic meaning and do not aid in  
> parsing the message.  Basically we appear to be changing:
> <soap:body> … <\soap:body> into
> <soap:body> <wrapper> …  <\wrapper><\soap:body>
>
> The reason we seem to be doing this is to support BP 1.1 – as noted  
> in the subject of the Issue.
>
> From our understanding, Basic Profile 1.1 was defined in a time  
> before Addressing was defined and so there were no action verbs.  In  
> order to solve this problem an outer element surrounding all soap  
> body messages was defined.  This outer element had semantic meaning  
> – it was the verb and was used to differentiate between soap  
> messages.  Each name had to be unique so that it could be used to  
> dispatch the messages correctly.  This is the reason the outer  
> element was created.
>
> If we were to follow Basic Profile 1.1 exactly, then each of the  
> outer elements (in this proposal called “wrappers”) would have to  
> have a unique name, so they could be used for dispatch as stated  
> above.  This is what the proposal does.
>
> So what is the value of this wrapper now that addressing has been  
> standardized in W3C?
> Does it really still aid interop?  (the original reason for the  
> existence of BP 1.1)
> Surely that is only possible if the outer element name was still  
> used as a verb instead of using Addressing actions?
>
> So it would seem that Transfer is designed to separate the verb from  
> the message, and BP 1.1 is designed to put the verb in the message.
>
> Re-iterating the three principles outlined in an earlier email:
> a) Transfer continues to have alignment with HTTP as much as possible.
> b) Transfer is built on WS-A and honors the WS-A action based  
> dispatch model.
> c) Transfer should be aligned with Basic Profile as much as possible.
> There is currently an open action item for Ashok to reach out to the  
> TAG and understand their real thoughts and goals around this issue.   
> We hope to hear from them soon.
>
> --Geoff
>
>
> From: Doug Davis [mailto:dug@us.ibm.com]
> Sent: Sunday, February 08, 2009 1:29 PM
> To: Geoff Bullen
> Cc: Gilbert Pilz; public-ws-resource-access@w3.org
> Subject: RE: issue 6398: updated proposal - HTTP Linkage
>
>
> Geoff,
>  this raises some interesting questions, points and possibilities.
> 1 - can you show me where this alignment of HTTP and Transfer is  
> viewed by the W3C Team/Tag as good thing?  As I've stated before,  
> the team comments [1] talk about a "parallel" between the two but  
> that is not the same thing as a statement of love.  In fact, the  
> rest of the team comments, and Tim's comments [2] could be  
> interpreted as the exact opposite.  The sharing of similar verbs is  
> not enough to "align" the two.  IMO, the key quote is (bolding is  
> mine):
> ...which means that WS-Transfer resources are potentially identified  
> by more than just a URI, making them unsuitable for referencing and  
> use in other Web technologies
> I'm having a hard time thinking of another WS spec that has caused  
> more tension between the Web/HTTP and SOAP worlds - aside from  
> perhaps WS-Addressing - and Transfer seems to have all of those same  
> criticisms plus more.
>
> 2 - you seem to be really straining hard to avoid using meaningful  
> XML elements in the Body.  Can you please explain why?  Most WS  
> specs have element names in the Body that are not meaningless and in  
> fact you yourself opened an issue for MEX to follow this same  
> pattern [3].  Why should WS-Transfer be different from the other WS  
> specs? I feel like there's something deeper here and you're not  
> letting us in on the secret.  Especially when in the note below you  
> now seem to be ok with a wrapper - but you want it to have an HTTP- 
> based meaning.
>
> 3 - you assert that "More than other specifications, Transfer should  
> continue to be aligned with HTTP", I actually very strongly disagree  
> with this.  Web Services are transport agnostic and any attempt to  
> make it favor one transport over another should not be allowed.
>
> 4 - WS-Transfer is, first and foremost, a SOAP specification.  Given  
> a choice between aligning with HTTP and the rest of the SOAP  
> specifications/stacks, I'd choose the latter.
>
> 5 - having said that, your insistence that WS-Transfer be aligned  
> with HTTP is an interesting perspective and one that I think we need  
> to consider further - especially given the W3C's concerns about its  
> lack of alignment with the Web itself.  I think in the interest of  
> trying to address the W3C concerns (and this alignment you seem to  
> see), I would suggest that we consider having WS-Transfer profile  
> its use of WS-Addressing so that it bans the use of reference- 
> parameters for identification purposes - in all transports.  (We may  
> even want to consider banning their use entirely just to really  
> force the issue).  And we then make a formal requirement that a  
> "naked HTTP GET" to the wsa:Address of a WS-Transfer resource's EPR  
> be the semantic equivalent of a WS-Transfer.Get to that same  
> resource. This requirement will ensure two things:  1) people aren't  
> ignoring the "no ref-params for identification purposes" rule, and  
> 2) address the W3C's concern about whether WS-Transfer resources  
> will play nicely with the rest of the Web technologies. IMO, this  
> will go a lot further to align HTTP and WS-Transfer than worrying  
> about the name of an XML wrapper.
>
> [1] http://www.w3.org/Submission/2006/04/Comment
> [2] http://lists.w3.org/Archives/Public/www-tag/2006Oct/0061.html
> [3] http://www.w3.org/Bugs/Public/show_bug.cgi?id=6500
>
> thanks
> -Doug
> ______________________________________________________
> STSM |  Standards Architect  |  IBM Software Group
> (919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
> Geoff Bullen <Geoff.Bullen@microsoft.com>
> 02/08/2009 01:03 PM
>
>
> To
> Gilbert Pilz <gilbert.pilz@oracle.com>
> cc
> Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org 
> >
> Subject
> RE: issue 6398: updated proposal - HTTP Linkage
>
>
>
>
>
>
>
>
>
> Gil,
> More than other specifications, Transfer should continue to be  
> aligned with HTTP.  Wrappers represent one area we can look at in  
> order to achieve that goal.  looking at RFC 2616, we note that it  
> uses some specific terms to refer to what Doug might be calling a  
> wrapper.
> Some possibilities we found we:
> body
> entity-body
> message-body
>
> Ashok, do you think that the TAG would find the use of any of these  
> terms as the wrapper for all 8 Transfer messages as further  
> indication of the alignment between Transfer and HTTP?  Is there  
> another wrapper name that would be more aligned?
>
> --Geoff
>
>
> From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
> Sent: Thursday, February 05, 2009 10:38 PM
> To: Geoff Bullen
> Cc: Doug Davis; public-ws-resource-access@w3.org
> Subject: Re: issue 6398: updated proposal - HTTP Linkage
>
> Geoff,
>
> Let me see if I understand your objections. You are saying (and  
> correct me if I am wrong) that, because Doug chose to name his  
> wrapper elements things like "wst:Get" and "wst:Put", this implies  
> that these wrappers will or should be regarded as verbs. Would it  
> make any difference if we called them "wst:Foo", "wst:FooResponse",  
> "wst:Baz", "wst:BazResponse", etc.?
>
> - gp
>
> Geoff Bullen wrote:
> Doug,
>
> Transfer and HTTP are already linked to some extent, I think we  
> agree on that, and from the number of emails going around concerning  
> this linkage, I suspect it is certainly one we need to look at more  
> closely.
>
> One of the ways in which Transfer and HTTP are currently linked, is  
> that they share a common model.
> As stated in an earlier email, the HTTP message body carries the  
> content (or message body) and not the verb (action).  In the same  
> way, the Transfer SOAP body carries the content and not the action.   
> In both cases, the action is handled separated from the message body.
>
> Now let’s look at your current wrapper proposal.
> While you call it a “wrapper” proposal, the names you use for those  
> wrapper elements are the same as the names of the associated actions  
> (verbs).  For example:
> The action: “http://.../transfer/GetResponse” directly maps to a  
> corresponding outer element in the body:
> wst:GetResponse ...>
>       xs:any +
> </wst:GetResponse>
> This is the pattern that is used throughout your wrapper proposal.
>
> Stating the obvious, there appears to be a direct correlation  
> between the action name and the name of the outer element of the  
> soap body (in this case “GetResponse”).  Whether implied or  
> intentional, this correlation breaks the basic model of separation  
> (of verb and content) described earlier.  Note that it also violates  
> the basic premise of addressing, that wsa:action is what is used to  
> differentiate messages.
>
> --Geoff
>
> From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org 
> ] On Behalf Of Doug Davis
> Sent: Wednesday, February 04, 2009 3:01 PM
> To: public-ws-resource-access@w3.org
> Subject: RE: issue 6398: updated proposal
>
>
> To follow-up on the conf call yesterday....
>
> Geoff mentioned the Team Comments on WS-Transfer [1] as an implicit  
> endorsement of the supposed alignment between HTTP and WS-Transfer.   
> However, I think this is not the case:
> - the team comments do not actually say that the "parallel" between  
> HTTP and WS-Transfer is a good thing it just points out that both  
> have similar verbs/operations.
> - in fact, after this similarity is pointed out the comments go on  
> to say how misaligned WS-Transfer is with the Web due to the use of  
> EPRs instead of URIs.  It says things like WS-Transfer resources  
> could be  "...unsuitable for referencing and use in other Web  
> technologies".
> - add to this Tim's comments [2], as Bob pointed out on the call,  
> that there is a concern over WS-Transfer's lack of alignment with  
> HTTP around such things as its use (or lack of use) of HTTP GET.   
> Its worth noting that Tim reiterates the concern about the  
> misalignment of WS-Transfer with the Web itself because of its use  
> of EPRs.
> - also, no where in the team comments do they make any reference to  
> the notion that because the Body is 'unwrapped' its more aligned  
> with HTTP.  It doesn't even touch on this subject at all.  And, as I  
> pointed out on the call, this would be a mistake for them to even  
> head down this path because there are lots of cases where the HTTP  
> Body is wrapped (like mime-encoding) and those are clearly not  
> misaligned with HTTP.
>
> I do agree with Geoff that the alignment of WS-Transfer with HTTP,  
> and the Web itself, should be more closely examined - especially  
> given the Team/Tag/Tim comments - but this is a separate issue that  
> has nothing to do with whether the Transfer operations include a  
> wrapper in the Body or not.
>
> [1]  http://www.w3.org/Submission/2006/04/Comment
> [2] http://lists.w3.org/Archives/Public/www-tag/2006Oct/0061.html
>
> thanks
> -Doug
> ______________________________________________________
> STSM |  Standards Architect  |  IBM Software Group
> (919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
>
> Geoff Bullen <Geoff.Bullen@microsoft.com>
> Sent by: public-ws-resource-access-request@w3.org
> 02/03/2009 12:35 PM
>
>
>
> To
> Doug Davis/Raleigh/IBM@IBMUS
> cc
> "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
> Subject
> RE: issue 6398: updated proposal
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi Doug,
> Having re-read our previous email a couple of times, it is still  
> kind of unclear exactly what you think we are in agreement on here.  
> J  While it is hopeful we will find common ground at some point, we  
> are not there yet.
>
> Regarding Transfer Create Operation …
>
> T.Create and RT.Create currently have different cardinalities and  
> one of them therefore must change in order for them to remain “in  
> sync”.
>
> The current version of T.Create() states that the first child  
> element MUST NOT be omitted. But the draft proposal allows senders  
> to emit empty Create requests. This means, current Transfer Resource  
> Factories cannot process the proposed Create request messages  
> without changing the underlying processing logic.
>
> Cheers,
> Geoff
>
>
>
> From: Doug Davis [mailto:dug@us.ibm.com]
> Sent: Monday, February 02, 2009 5:27 PM
> To: Geoff Bullen
> Cc: public-ws-resource-access@w3.org
> Subject: RE: issue 6398: updated proposal
>
>
> Geoff,
> thanks for the comments.  I'm glad that we're in agreement that  
> there is no functional difference between what the current version  
> of Transfer and my proposal because I tried to ensure that it was  
> just a syntax change.  As to the change of cardinality of Create, I  
> was very clear as to why I changed it - please reread my proposal.   
> Also, it does not break backwards compatibility - aside from the  
> addition of a wrapper, existing impls will still be sending valid WS- 
> T messages.
>
> thanks
> -Doug
> ______________________________________________________
> STSM |  Standards Architect  |  IBM Software Group
> (919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
>
> Geoff Bullen <Geoff.Bullen@microsoft.com>
> 02/02/2009 07:32 PM
>
>
>
>
>
> To
> Doug Davis/Raleigh/IBM@IBMUS
> cc
> "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
> Subject
> RE: issue 6398: updated proposal
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Doug,
> We have been looking more closely at the wrapper issue (Issue 6398)  
> and your current proposal and there are a number of concerns that we  
> have.
>
> Summary
> We believe that the proposed changes will affect the current  
> alignment of Transfer with HTTP, and that it breaks the current  
> implementation of Transfer by changing the cardinality of  message  
> formats.  More specific details can be seen below:
>
> 1) Wrappers and the Alignment of Transfer with HTTP
> We believe that the proposed wrapper changes disrupt the current  
> alignment between Transfer and HTTP.  Since the TAG articulated in  
> Nov, 2008 that they were interested in a closer alignment between  
> Transfer and HTTP, it is unclear to us if this is the right  
> direction for the WG to be heading.
>
> There are a set of principles that guide us as we move through this  
> issue:
> a) Transfer continues to have alignment with HTTP as much as possible.
> b) Transfer is built on WS-A and honors the WS-A action based  
> dispatch model.
> c) Transfer should be aligned with Basic Profile as much as possible.
>
> With regards to goal a) above, the HTTP message body carries the  
> content (or message body) and not the verb (action).  In the same  
> way, the Transfer SOAP body carries the content and not the action.  
> We believe using specific wrapper element names, such as <get> and  
> <getresponse>, implies there is semantic meaning in those names,  
> which affects the separation described above and thus disrupts the  
> existing alignment between Transfer and HTTP.  Any semantic meaning  
> also goes against goal b).
>
> Also with regards to goal a), the WG has not yet received any  
> technical comments from the TAG nor has the TAG articulated its  
> wishes clearly to us.  Shouldn't we engage the TAG ASAP?
>
>
> 2) Wrappers, Cardinality and the Create verb
> While you expressed a desire to treat cardinality as separate from  
> the wrapper issue, your proposal does in fact change the cardinality  
> of the Transfer messages, Delete and Create.  While changing the  
> cardinality of T.delete does not break backwards compatibility,  
> changing the cardinality of T.create certainly does.  It is unclear  
> to us why your proposal has chosen to break backwards compatibility  
> with T implementations.  It is our understanding that there are many  
> current interoperable implementations of the T spec, so would not it  
> be more prudent to align more closely with the current version of T?
>
> --Geoff
>
>
> From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org 
> ] On Behalf Of Doug Davis
> Sent: Sunday, January 18, 2009 10:34 AM
> To: public-ws-resource-access@w3.org
> Subject: RE: issue 6398: updated proposal
>
>
> Hey Geoff,
> thanks for the heads up on the cardinality - I'll double check those  
> - but what's correct depends on whether you're looking at the schema  
> or the text of the spec.  For example, GetResponse, per the pseudo  
> schema should be as you noted (+), but per the schema it should be a  
> singleton.  Either way - this is our chance to make sure things are  
> aligned. As for the MEX change, despite some possible ribbing from  
> Jeff :-), I like consistency - so if you open an issue I wouldn't  
> object.
>
> All,
> below is a modified version of the proposal, showing the pseudo  
> schema changes to T and RT (some of the cardinalities will vary  
> slightly from previous proposal and from the specs in an effort to  
> ensure things are consistent and allow for RT to do its job) - I  
> tried to make a note of each one as I detected it (hopefully the  
> following shows up ok for everyone - if not let me know and I'll put  
> it into a separate file):
>
> T-GetRequest:                 RT-GetRequest:
> <wst:Get ... >                <wst:Get Dialect="xs:anyURI" ...>
> xs:any *                       <wsrt:Expression ...> xs:any </ 
> wsrt:Expression> *
> </wst:Get>                    </wst:Get>
> Note: to allow for more than one Expression, I had to change the  
> 'xs:any ?' to a "xs:any *" on the xs:any of the T.Get(), and for  
> full extensibility (an attribute on Get could make the need for  
> children unnecessary).
>
> T-GetResponse:                RT-GetResponse:
> <wst:GetResponse ...>         <wst:GetResponse ...>
> xs:any +                         <wsrt:Result...>xs:any</ 
> wsrt:Result> +
> </wst:GetResponse>            </wst:GetResponce>
> Note: We should consider changing the "xs:any +" to "xs:any *" since  
> the resource representation could technically be empty and we should  
> allow for that (<wsrt:Result>+ too), and for full extensibility (an  
> attribute on GetResponse could make the need for children  
> unnecessary).
>
> T-PutRequest:                 RT-PutRequest:
> <wst:Put ...>                 <wst:Put Dialect="xs:anyURI" ...>
> xs:any +                       <wsrt:Fragment ...> +
> </wst:Put>                    <wst:Put>
> Note: We should change "xs:any +" to "xs:any *" to allow for an  
> empty represenation to be 'put', and for full extensibility (an  
> attribute on Put could make the need for children unnecessary).
>
> T-PutResponse:                RT-PutResponse:
> <wst:PutResponse ...>         <wst:PutResponse ...>
> xs:any ?                       xs:any ?
> </wst:PutResponse>            </wst:PutResponse>
> Note: We should change the "xs:any ?" to "xs:any *" to allow for  
> full extensbility.
>
> T-DeleteRequest:              RT-DeleteRequest:
> <wst:Delete ...>              <wst:Delete ...>
> xs:any *                      xs:any *
> </wst:Delete>                 </wst:Delete>
> Note: I added the "xs:any *" extensibility point in here.
>
> T-DeleteResponse:             RT-DeleteResponse:
> <wst:DeleteResponse ...>      <wst:DeleteResponse>
> xs:any ?                       xs:any ?
> </wst:DeleteResponse>         </wst:DeleteResponse>
> Note: We should change the "xs:any ?" to "xs:any *" to allow for  
> full extensbility.
>
> T-CreateRequest:              RT-CreateRequest:
> <wst:Create ...>              <wst:Create Dialect="xs:anyURI" ...>
> xs:any *                       <wsmex:Metadata ...> ?
>                             <wsrt:Fragment ...> *
> </wst:CreateRequest>          </wst:CreateRequest>
> Note: I changed the "xs:any +" to "xs:any *" for three reasons: 1)  
> it seems like it should be possible to allow the entire resource to  
> have default values, 2) per the RT spec the mex and fragment  
> elements are optional, 3) to allow for full extensibility (an  
> attribute on the Create could make up for the absence of child  
> elements).
>
> T-CreateResponse:             RT-CreateResponse:
> <wst:CreateResponse ...>      <wst:CreateResponse ...>
> <wst:ResourceCreated>         <wst:ResourceCreated>
> xs:any ?                      xs:any ?
> </wst:CreateResponse>         </wst:CreateResponse>
> Note: We should change the "xs:any ?" to "xs:any *" to allow for  
> full extensbility.
>
> We should discuss the "xs:any ?" -> "xs:any *" notes I made - if  
> there isn't any objection we can include it as part of this.
>
> thanks
> -Doug
> ______________________________________________________
> STSM  |  Web Services Architect  |  IBM Software Group
> (919) 254-6905  |  IBM T/L 444-6905  |  dug@us.ibm.com
>
> Geoff Bullen <Geoff.Bullen@microsoft.com>
> Sent by: public-ws-resource-access-request@w3.org
> 01/16/2009 12:09 PM
> To
> Doug Davis/Raleigh/IBM@IBMUS
> cc
> "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
> Subject
> RE: issue 6398: updated proposal
>
>
>
>
>
>
>
> Doug,
> A couple of things:
> 1)      I believe the "xs:any" defined in GetResponse, PutRequest,  
> CreateRequest should actually be "xs:any +" defining  one or more.
> 2)      I am wondering if, for the sake of consistency and  
> extensibility, we should also be looking at the GetMetadata Request  
> and Response messages in MEX and adding a similar outer wrappers and  
> extensibility concepts?
> Thoughts?
> --Geoff
>
> From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org 
> ] On Behalf Of Doug Davis
> Sent: Thursday, January 15, 2009 6:36 AM
> To: public-ws-resource-access@w3.org
> Subject: issue 6398: updated proposal
>
>
> per my AI from yesterday, the updated pseudo schema for the wrapped  
> WS-Transfer operations would be:
>
> GetRequest:
> <wst:Get ... >
> xs:any ?
> </wst:Get>
>
> GetResponse:
> <wst:GetResponse ...>
> xs:any
> </wst:GetResponse>
>
> PutRequest:
> <wst:PutRequest ...>
> xs:any
> </wst:PutRequest>
>
> PutResponse:
> <wst:PutResponse ...>
> xs:any ?
> </wst:PutResponse>
>
> DeleteResponse:
> <wst:DeleteResponse ...>
> xs:any ?
> </wst:DeleteResponse>
>
> CreateRequest:
> <wst:CreateRequest ...>
> xs:any
> </wst:CreateRequest>
>
> CreateResponse:
> <wst:CreateResponse ...>
> <wxf:ResourceCreated>endpoint-reference</wxf:ResourceCreated>
> xs:any ?
> </wst:CreateResponse>
>
> In looking at how this impacts RT... it shouldn't. RT overrides T's  
> Body (in some cases already using a wrapper similar to the above) so  
> that can continue as is. The only thing missing from the previous  
> proposal was the extensibilty points on the wrapper elements so that  
> attributes could be added - but that was a typo :-) .  Existing RT  
> can continue to override the the above messages with a well defined  
> element - this, along with the RT header allows the receiver to know  
> this isn't a normal/vanilla Transfer operation.
>
> There is no impact on MEX.  I couldn't find any reference to the  
> transfer operations that needed to be changed - no samples using it  
> either.
>
> thanks
> -Doug
> ______________________________________________________
> STSM  |  Web Services Architect  |  IBM Software Group
> (919) 254-6905  |  IBM T/L 444-6905  |  dug@us.ibm.com
>
>