W3C home > Mailing lists > Public > public-ws-resource-access@w3.org > May 2009

Re: Issue 6712 Discussion and Proposal

From: Gilbert Pilz <gilbert.pilz@oracle.com>
Date: Thu, 28 May 2009 16:23:29 -0700
Message-ID: <4A1F1CF1.9020908@oracle.com>
To: David Snelling <David.Snelling@UK.Fujitsu.com>
CC: public-ws-resource-access@w3.org
Dave,

W/respect to (d) it seems to me that the client can always turn around 
and do a Get on /wst:CreateResponse/wst:ResourceCreated and check to see 
if what got created was what it expected but this seems like an awfully 
inefficient and error prone way of solving this problem.

I agree with you about the @Dialect attribute. I think it is the 
cleanest way to solve this problem. It should also be accompanied by a 
class of nested policy assertions that the resource manager can use to 
advertise which dialects it supports. Since @Dialect and these policy 
assertions are optional, the base case collapses to your solution (a), 
which is to use the 'literal resource representation'.

- gp

On 5/11/2009 2:16 AM, David Snelling wrote:
> Folks,
>
> It is clear to me that there are 2 semantics inferred in the T-spec 
> for create that a service may support. 
>
> 1) Make the payload the resource.
>
> 2) Use the payload in some way to make the resource.
>
> As Geoff pointed out the service gets to decide which it supports or 
> if it supports both. The spec is not even clear which is the default 
> mode, so a client should consult a policy framework before proceeding. 
> So we at least need to define a pair of URIs to use in a policy 
> framework. As it stands the service may behave contrary to the 
> client's assumption and the client will remain totally unaware of what 
> semantic the service acted on.
>
> I prefer the Dialect proposal, but I see a couple of other solutions. 
> a) We could mandate a single semantic only, probably (1) above. b) We 
> could allow both but a service MUST advertise which it supports in a 
> policy framework. c) Add another version of the create operation, d) 
> Mandate that the service always send back the resulting 
> representation, so the client can check it and retry if the result is 
> not what was expected.
>
> On 07 May 2009, at 14:20, Doug Davis wrote:
>
>>
>> Geoff,
>>   I forgot to mention that your solution actually doesn't work.  As a 
>> service there are two types of Creates I might support (both legal 
>> and advocated in the T spec):
>> 1) Create where I pass in the xml representation as a child of the 
>> Create
>> 2) an 'instruction based' Create where the QName of the Create tells 
>> me the instruction
>> Obviously the QName of the child element in case #2 is not defined by 
>> T so it will be service specific.  However, case #1 is something that 
>> should work across all implementations of Transfer.  As a service 
>> provider if I want to offer up both, your solution would not work for 
>> me.  You're asking me to remove case #1 and make my implementation 
>> totally non-interoperable.  Yes, clearly, case #2 will only be 
>> interoperable with other endpoints that know about my service 
>> specific QName and that's ok.  However, what's not ok is for me to 
>> have to remove case #1 because that's the baseline for interop that I 
>> need to ensure the broadest support.  So, in terms of "bad 
>> architectural decisions" that one would be pretty high on my list.
>>
>> thanks
>> -Doug
>> ______________________________________________________
>> STSM |  Standards Architect  |  IBM Software Group
>> (919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com 
>> <mailto:dug@us.ibm.com>
>> The more I'm around some people, the more I like my dog.
>>
>>
>> *Doug Davis/Raleigh/IBM@IBMUS*
>> Sent by: public-ws-resource-access-request@w3.org 
>> <mailto:public-ws-resource-access-request@w3.org>
>>
>> 05/06/2009 09:07 PM
>>
>> 	
>> To
>> 	public-ws-resource-access@w3.org 
>> <mailto:public-ws-resource-access@w3.org>
>> cc
>> 	
>> Subject
>> 	RE: Issue 6712 Discussion and Proposal
>>
>>
>>
>> 	
>>
>>
>>
>>
>>
>>
>> I actually agree.  The WS-Transfer team that wrote the spec made a 
>> very bad architecture decision by explicitly saying that something 
>> can be done but not provide a way for it to actually happen.  Glad we 
>> can finally agree on something.
>>
>> I accept your modified proposal to rename the attribute.
>>
>> thanks
>> -Doug
>> ______________________________________________________
>> STSM |  Standards Architect  |  IBM Software Group
>> (919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com 
>> <mailto:dug@us.ibm.com>
>> The more I'm around some people, the more I like my dog.
>>
>> *Geoff Bullen <Geoff.Bullen@microsoft.com 
>> <mailto:Geoff.Bullen@microsoft.com>>*
>>
>> 05/06/2009 08:56 PM
>>
>> 	
>> To
>> 	Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org 
>> <mailto:public-ws-resource-access@w3.org>" 
>> <public-ws-resource-access@w3.org 
>> <mailto:public-ws-resource-access@w3.org>>
>> cc
>> 	
>> Subject
>> 	RE: Issue 6712 Discussion and Proposal
>>
>>
>>
>>
>> 	
>>
>>
>>
>>
>>
>>
>> Doug,
>> >From the email below, we assume that:
>>  
>> <Body>
>> <doit xmlns="urn:foo"/>
>> </Body>
>>  
>> Actually means:
>>  
>> [Body]
>> <create>
>> <Body>
>> <doit xmlns="urn:foo"/>
>> </Body>
>>            </create>
>>  
>> The server is in complete control of definition and contents of the 
>> first child element, in this case an element called “body”.
>>  
>> The line of reasoning followed by IBM in the mail thread below seems 
>> to be that the Server implementer deliberately chooses to use the 
>> “body” element above, so that the Server code cannot tell the 
>> difference between the incoming elements in a Create message.  The 
>> implementer does this rather than choosing a different strategy such 
>> as the one we suggest below, where the Server could easily tell the 
>> difference.
>>  
>> This same line of reasoning seems to continue that, because it is 
>> possible for the Server implementer to make such a really bad 
>> architectural decision, the WG should accommodate this use case by 
>> creating an brand new attribute in the Transfer spec (just for 
>> Create) to allow the client the specify which one is really meant. 
>>  But, of course, the Server implementer, having worked out that it is 
>> a really bad architecture, now has to also add new Server code to 
>> support this new attribute in order to “hack the fix in”, rather than 
>> simply add code to correct the actual architectural issue.
>>  
>> Perhaps we should call this new attribute <create 
>> usingReallyBadImplementation=”1”> ?
>>  
>> --Geoff
>>  
>>  *
>> From:* public-ws-resource-access-request@w3.org 
>> [mailto:public-ws-resource-access-request@w3.org] *On Behalf Of *Doug 
>> Davis*
>> Sent:* Wednesday, May 06, 2009 3:45 PM*
>> To:* public-ws-resource-access@w3.org 
>> <mailto:public-ws-resource-access@w3.org>*
>> Subject:* RE: Issue 6712 Discussion and Proposal
>>  
>>
>> The server. If the server supports both (meaning it accept both an 
>> instruction and storing of xs:any) and the Body looks like:
>> <Body>
>> <doit xmlns="urn:foo"/>
>> </Body>
>>
>> is it a chunk of XML or is it the "doit" instruction?  It (the 
>> server) can't tell.
>>
>> thanks
>> -Doug
>> ______________________________________________________
>> STSM |  Standards Architect  |  IBM Software Group
>> (919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com 
>> <mailto:dug@us.ibm.com>
>> The more I'm around some people, the more I like my dog.
>>
>> *Geoff Bullen <Geoff.Bullen@microsoft.com 
>> <mailto:Geoff.Bullen@microsoft.com>>*
>> Sent by: public-ws-resource-access-request@w3.org 
>> <mailto:public-ws-resource-access-request@w3.org>
>>
>> 05/06/2009 06:29 PM
>>
>> 	
>> To
>> 	Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org 
>> <mailto:public-ws-resource-access@w3.org>" 
>> <public-ws-resource-access@w3.org 
>> <mailto:public-ws-resource-access@w3.org>>
>> cc
>> 	
>> Subject
>> 	RE: Issue 6712 Discussion and Proposal
>>
>>
>>
>>  
>>
>>
>>
>> 	
>>
>>
>>
>>
>>
>>
>>
>> > … but doesn't provide a way to unambiguously know which it is.
>>
>> Doug,
>> Who is it that has to unambiguously know?  The client?  The server? 
>>  Each of these does unambiguously know.
>> --Geoff
>> *
>> From:* public-ws-resource-access-request@w3.org 
>> [mailto:public-ws-resource-access-request@w3.org] *On Behalf Of *Doug 
>> Davis*
>> Sent:* Wednesday, May 06, 2009 3:22 PM*
>> To:* public-ws-resource-access@w3.org 
>> <mailto:public-ws-resource-access@w3.org>*
>> Subject:* RE: Issue 6712 Discussion and Proposal
>>
>>
>> Geoff,
>> that solution, while technically possible, implies that we can not 
>> use Transfer the way it was designed.  It says:
>>
>> [Body]/wst:Create
>>  If this REQUIRED element contains children then the first child MUST 
>> be the literal resource representation, a representation of the 
>> constructor for the resource, or other instructions for creating the 
>> resource.
>>
>> It allows for the immediate child of the Create element to be either 
>> the XML or an instruction, but doesn't provide a way to unambiguously 
>> know which it is.
>>
>> thanks
>> -Doug
>> ______________________________________________________
>> STSM |  Standards Architect  |  IBM Software Group
>> (919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com 
>> <mailto:dug@us.ibm.com>
>> The more I'm around some people, the more I like my dog.
>>
>> *Geoff Bullen <Geoff.Bullen@microsoft.com 
>> <mailto:Geoff.Bullen@microsoft.com>>*
>>
>> 05/06/2009 05:56 PM
>>
>> 	 
>>
>>
>> To
>> 	Doug Davis/Raleigh/IBM@IBMUS
>> cc
>> 	"public-ws-resource-access@w3.org 
>> <mailto:public-ws-resource-access@w3.org>" 
>> <public-ws-resource-access@w3.org 
>> <mailto:public-ws-resource-access@w3.org>>, 
>> "public-ws-resource-access-request@w3.org 
>> <mailto:public-ws-resource-access-request@w3.org>" 
>> <public-ws-resource-access-request@w3.org 
>> <mailto:public-ws-resource-access-request@w3.org>>
>> Subject
>> 	RE: Issue 6712 Discussion and Proposal
>>
>>
>>
>>
>>  
>>
>>  
>>
>>
>>
>> 	
>>
>>
>>
>>
>>
>>
>> > *If I have a transfer service that is storing a blob of xml in a DB 
>> and it allows the XML to be anything - how do I know if the client 
>> meant for it to be stored "as is" or for the QName to indicate an 
>> instruction?  Assuming of course that the service supports 
>> instructions as well.*
>>
>> Doug,
>> The Transfer service is in control, it knows its own content, and it 
>> knows the difference between blobs and instructions.  If the 
>> situation quoted above arises for a particular Transfer service, then 
>> it could easily distinguish between blobs and instructions using some 
>> strategy such as:
>>
>> Request from client to transfer service to create a blob:
>> [body]
>> <create>
>>   <blob>
>>      … contents of blob to be stored in DB (any XML can be put here) …
>>   </blob>
>> </create>
>>
>> Request from client to transfer service to create resource using a 
>> set of rules:
>> [body]
>> <create>
>>   <MyInstructions>
>>      … set of instructions defined here (only instruction specific 
>> XML can be put here) …
>>   </MyInstructions>
>> </create>
>> *
>>
>> From:* Doug Davis [mailto:dug@us.ibm.com] *
>> Sent:* Wednesday, May 06, 2009 7:54 AM*
>> To:* Geoff Bullen*
>> Cc:* public-ws-resource-access@w3.org 
>> <mailto:public-ws-resource-access@w3.org>; 
>> public-ws-resource-access-request@w3.org 
>> <mailto:public-ws-resource-access-request@w3.org>*
>> Subject:* RE: Issue 6712 Discussion and Proposal
>>
>>
>> > Even HTTP itself has a "message format" flag - its called 
>> "Content-Type".
>>
>> Doug, it is good that you are wanting to model Transfer after HTTP. 
>>  The Content-Type field is used to indicate the media type of the 
>> underlying data. The media type of a SOAP message is well defined. 
>> The type of the first child element of a Create message can be 
>> inferred from the QName of the first child element. *
>>
>> I wouldn't assume that ;-)  I only mentioned it because I know you 
>> like to make the comparison.  I actually am not fond of it because 
>> you're being very selective about which bits of HTTP to mimic - 
>> basically just the ones you like and ignoring the others.  For 
>> example, HTTP has the notion of fragments - two different ways (# in 
>> the URL and Range headers).* *
>> As for the QName... see below.*
>>
>> > the QName of the child can tell you most everything you need to 
>> know - however, the one case of the resource being an xs:any is still 
>> left ambiguous
>>
>> Why is this ambiguous and to whom is it ambiguous?  Even though it 
>> has been defined as an xs:any in the Transfer schema, it is clearly 
>> defined by the Service that implements it (this is stated by the 
>> spec).  It is not ambiguous to the Service at all, nor the client, 
>> since the client knows what the Service demands. *
>>
>> If I have a transfer service that is storing a blob of xml in a DB 
>> and it allows the XML to be anything - how do I know if the client 
>> meant for it to be stored "as is" or for the QName to indicate an 
>> instruction?  Assuming of course that the service supports 
>> instructions as well.*
>>
>> thanks
>> -Doug
>> ______________________________________________________
>> STSM |  Standards Architect  |  IBM Software Group
>> (919) 254-6905  |  IBM 444-6905  |  _dug@us.ibm.com_ 
>> <mailto:dug@us.ibm.com>
>> The more I'm around some people, the more I like my dog.
>>
>> *Geoff Bullen <**_Geoff.Bullen@microsoft.com_* 
>> <mailto:Geoff.Bullen@microsoft.com>*>*
>>
>> 05/06/2009 10:39 AM
>>
>> 	 
>>
>>  
>>
>>
>> To
>> 	Doug Davis/Raleigh/IBM@IBMUS
>> cc
>> 	"_public-ws-resource-access@w3.org_ 
>> <mailto:public-ws-resource-access@w3.org>" 
>> <_public-ws-resource-access@w3.org_ 
>> <mailto:public-ws-resource-access@w3.org>>, 
>> "_public-ws-resource-access-request@w3.org_ 
>> <mailto:public-ws-resource-access-request@w3.org>" 
>> <_public-ws-resource-access-request@w3.org_ 
>> <mailto:public-ws-resource-access-request@w3.org>>
>> Subject
>> 	RE: Issue 6712 Discussion and Proposal
>>
>>
>>
>>  
>>
>>  
>>
>>  
>>
>>
>>
>> 	
>>
>>
>>
>>
>>
>>
>> > Even HTTP itself has a "message format" flag - its called 
>> "Content-Type".
>>
>> Doug, it is good that you are wanting to model Transfer after HTTP. 
>>  The Content-Type field is used to indicate the media type of the 
>> underlying data. The media type of a SOAP message is well defined. 
>> The type of the first child element of a Create message can be 
>> inferred from the QName of the first child element.
>>
>> > the QName of the child can tell you most everything you need to 
>> know - however, the one case of the resource being an xs:any is still 
>> left ambiguous
>>
>> Why is this ambiguous and to whom is it ambiguous?  Even though it 
>> has been defined as an xs:any in the Transfer schema, it is clearly 
>> defined by the Service that implements it (this is stated by the 
>> spec).  It is not ambiguous to the Service at all, nor the client, 
>> since the client knows what the Service demands.
>>
>> --Geoff *
>>
>>
>> From:* Doug Davis _[mailto:dug@us.ibm.com]_ 
>> <mailto:%5Bmailto:dug@us.ibm.com%5D> *
>> Sent:* Tuesday, May 05, 2009 3:11 PM*
>> To:* Geoff Bullen*
>> Cc:* _public-ws-resource-access@w3.org_ 
>> <mailto:public-ws-resource-access@w3.org>; 
>> _public-ws-resource-access-request@w3.org_ 
>> <mailto:public-ws-resource-access-request@w3.org>*
>> Subject:* Re: Issue 6712 Discussion and Proposal
>>
>>
>> This does not address the usecase that I'm worried about [1] nor the 
>> issue.  Even HTTP itself has a "message format" flag - its called 
>> "Content-Type".  In cases where there are multiple ways to interpret 
>> the data (which is something that Transfer itself promotes) it only 
>> seems logical for Transfer to provide the mechanism by which users of 
>> the spec can do that.  We don't need to specify much since the QName 
>> of the child can tell you most everything you need to know - however, 
>> the one case of the resource being an xs:any is still left ambiguous.
>>
>> [1] 
>> _http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0142.html_ 
>>
>>
>> thanks
>> -Doug
>> ______________________________________________________
>> STSM |  Standards Architect  |  IBM Software Group
>> (919) 254-6905  |  IBM 444-6905  |  _dug@us.ibm.com_ 
>> <mailto:dug@us.ibm.com>
>> The more I'm around some people, the more I like my dog.
>>
>> *Geoff Bullen <**_Geoff.Bullen@microsoft.com_* 
>> <mailto:Geoff.Bullen@microsoft.com>*>*
>> Sent by: _public-ws-resource-access-request@w3.org_ 
>> <mailto:public-ws-resource-access-request@w3.org>
>>
>> 05/05/2009 01:05 PM
>>
>> 	 
>>
>>  
>>
>>  
>>
>>
>> To
>> 	"_public-ws-resource-access@w3.org_ 
>> <mailto:public-ws-resource-access@w3.org>" 
>> <_public-ws-resource-access@w3.org_ 
>> <mailto:public-ws-resource-access@w3.org>>
>> cc
>> 	
>> Subject
>> 	Issue 6712 Discussion and Proposal
>>
>>
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>
>>
>> 	
>>
>>
>>
>>
>>
>> After further consideration of Issue 6712 
>> (_http://www.w3.org/Bugs/Public/show_bug.cgi?id=6712_), which 
>> concerns the Create message in Transfer, we don’t really think it 
>> matters if the spec is inferring that a given service or resource can 
>> support more than one format of Create Message or not.  First, a few 
>> assumptions:
>> a)     Each Service is ultimately responsible for deciding what type 
>> and format of information is sent in a Create message.
>> b)     Each Service will define its own set of “creation rules” (if 
>> any) which will be used to create its resources.  That is, the WG 
>> will not define some common creation rules language that will be used 
>> by all resources.  A Service may even support more than one format of 
>> creation rules if it wants to.
>>
>> Since the service is responsible for providing the definition of each 
>> Create message format it supports, it is also responsible for 
>> demining how it will tell the difference between those multiple 
>> formats when they occur in a Create message.   One way that the 
>> service might easily do this is as follows:
>>
>> Defining the literal Resource to create:
>> [Header]
>>           <wsam:Action>…/ws-tra/Create</wsam:Action>
>> [Body]
>> <Create>
>>           <xxx:MyResource>
>>                          Resource Definition here
>>           </xxx:MyResource>
>> </Create>
>>
>> Defining a set of rules to create a Resource:
>> [Header]
>>           <wsam:Action>…/ws-tra/Create</wsam:Action>
>> [Body]
>> <Create>
>>           <xxx:MyRules>
>>                          Rules here
>>           </xxx:MyRules>
>> </Create>
>>
>> In the end, there is no real difference between these two examples. 
>> It is not clear then what the value is in providing a means within 
>> the protocol for determining the message format (e.g. a resource or 
>> rule flag).  Since the resource (service) is responsible for the 
>> definition of both “MyResource” and “MyRules” there is literally 
>> nothing extra in the Transfer protocol that is needed to help the 
>> resource understand the type of “instructions” it has been sent in a 
>> Create message.  To add some flag to the Transfer protocol seems 
>> purely redundant and unnecessary.
>>
>> Based on the feedback from the WG, it does seem like some clarifying 
>> text is required, we propose:
>>
>> [Body]/wst:Create
>>
>> This REQUIRED element MAY contain zero or more child elements. If 
>> this element does not contain a child element then the resource will 
>> be created using default values. The first child element, if present, 
>> is service-specific (or the interpretation of the first child element 
>> is defined by the resource to which the create message is addressed) 
>> and MUST be the literal resource representation, a representation of 
>> the constructor for the resource, or other instructions for creating 
>> the resource. Additional extension elements MAY be included only 
>> after the mandated first child element.
>>
>> --Geoff
>>
>>  
>>
>>
>
> 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.
>


Received on Thursday, 28 May 2009 23:24:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:18:00 GMT