- From: Doug Davis <dug@us.ibm.com>
- Date: Sun, 18 Jan 2009 13:34:28 -0500
- To: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
- Message-ID: <OFFCF85083.E7FF3F19-ON85257542.005E208E-85257542.00660A94@us.ibm.com>
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
Received on Sunday, 18 January 2009 18:35:17 UTC