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