RE: issue 6398: updated proposal - HTTP Linkage

Geoff,
  The wrappers are not "semantically meaningless".  In our discussions 
we've talking about how this change will have no real impact on existing 
implementations and I think from that notion some people are assuming 
they're meaningless.  This isn't true.  Aside from making things BP 
compliant by replacing a "type" with a GED it does a few other things....

- like all good rules there might be exceptions, but pretty much all WS 
specs follow the same pattern w.r.t. how their Body elements look.  They 
have a well defined GED in the Body that describes the operation.  Yes it 
may be a dup of what the wsa:Action says but that doesn't change the fact 
that this is a pattern that is followed.  Geoff, you yourself opened an 
issue for MEX to follow this pattern as well for GetMetadataResponse.  So, 
to me the question on this point isn't whether or not WS-Transfer should 
be changed to follow the well established pattern we see for basically all 
other WS specs, but instead we should be asking why WS-Transfer chose to 
pick a different pattern for no apparent reason?  In other words, rather 
than trying to justify this "pattern" - I think its incumbent on people to 
justify why WS-Transfer _must_ not follow the pattern?

- the wrapper allows for people to use WS-Transfer the way it was actually 
written.  If we look at certain messages, like GetResponse, it allows for 
multiple children in the Body.  Yes this violates BP and adding a wrapper 
fixes that issue - which is a good thing - but there's something else 
here.  Many soap stacks only support one child in the Body.  Looking at 
WS-Management (which is probably the biggest user right now of 
ws-transfer), it specifically talks about this:
R7.6-6: The response shall not contain the initial representation of the 
object, in spite of language within the WS-Transfer specification.
This last restriction is due to the fact that some SOAP processors cannot 
process multiple child elements within a SOAP s:Body.
So, WS-Management had to actually violate WS-Transfer just to take reality 
into account because so many people couldn't support multiple children in 
the Body.  By adding a wrapper to the operations we can allow these 
operations to have multiple elements (and keep their full set of features) 
and still work in today's soap stacks.  IMO, it says a lot when the first 
main user of a spec had to violate it just to make it work in practice. 
Again, why does WS-Transfer need break existing implementations?

The consistent theme I hear from the proponents of the current WS-Transfer 
choice is that they would prefer for the rest of the WS community be 
changed to adhere to a specification that not only doesn't following the 
well established interop principles of BP but also doesn't take into 
account the implementations choices that many have made.  And they want to 
force this change without any justification.  To be fair, if there was a 
technical reason that WS-Transfer could not get its job done w/o violating 
BP, these patterns, or common implementation choices then I could be 
convinced that people just need to suck it up and change their code and 
forget about BP.  But this just isn't the case here. 

So again, I'd like to hear why WS-Transfer _must_ be different, _must not_ 
adhere to BP, _must not_ adhere to the patterns we see in pretty much all 
other WS spec, _must_ force some existing soap stacks to change some 
fundamental design choices to support things like multiple children in the 
Body?  IMO, the exception needs to be justified, not the rule.

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/20/2009 12:49 PM

To
Christopher B Ferris/Waltham/IBM@IBMUS
cc
Doug Davis/Raleigh/IBM@IBMUS, Gilbert Pilz <gilbert.pilz@oracle.com>, 
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>, 
"public-ws-resource-access-request@w3.org" 
<public-ws-resource-access-request@w3.org>
Subject
RE: issue 6398: updated proposal - HTTP Linkage






Hi Chris,
Thanks for the email, and I appreciate your feedback and involvement.  To 
paraphrase, you seem to be saying that the root cause of the issue here is 
not about dispatching at runtime, but about design time tools, and their 
ability to consume an appropriate message format.  In particular, BP has 
placed some restrictions (R2204) on the WSDL language such that is it no 
longer possible for some tools to consume a message that is not wrapped in 
an outer element.
 
At first glance, this appears to put the RA Working Group in a rather 
difficult position.  On one hand we have a charter that states that we 
should try to align with BP whenever it is appropriate.  On the other, we 
have a responsibility to W3C (and the WS community in general) to produce 
the best protocol possible, so it has the highest chance of gaining wide 
industry adoption.  From your email, it seems that this particular BP 
restriction is forcing some members of the WG  to advocate a semantically 
useless wrapper element be inserted around 8 fundamental Web Service 
messages (The Transfer messages) for no reason other than the fact that 
their design tools cannot consume the appropriate message formats.  This 
does not seem right.  Perhaps we should help the design tool vendors by 
relaxing Basic Profile to allow this important use case rather than have 
its effects cause the WG to produce sub-optimal specifications?  Do you 
have any critical reasons why these wrapper elements should be specified 
other than just to conform to BP?
 
Best Regards,
Geoff
 
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
Sent: Wednesday, February 11, 2009 4:40 AM
To: Geoff Bullen
Cc: Doug Davis; Gilbert Pilz; public-ws-resource-access@w3.org; 
public-ws-resource-access-request@w3.org
Subject: RE: issue 6398: updated proposal - HTTP Linkage
 
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