- From: Gilbert Pilz <gilbert.pilz@oracle.com>
- Date: Thu, 28 May 2009 13:48:28 -0700
- To: Geoff Bullen <Geoff.Bullen@microsoft.com>
- CC: Doug Davis <dug@us.ibm.com>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
- Message-ID: <4A1EF89C.2030607@oracle.com>
Geoff, Yes, there is no definition of the term "literal resource representation" in WS-T. I read your statements as a claim that the absence of this definition was deliberate and was meant to indicate that there is no implied constraint on what such a representation might be. However, since the Member Submission of WS-Transfer was incomplete (as evidenced by 6632 <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6632>, 6633 <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6633>, 6533 <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6533>, 6551 <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6551>, 6672 <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6672>, 6673 <http://www.w3.org/Bugs/Public/show_bug.cgi?id=6673> etc.), it seems is far more likely to me that the lack of a definition for "literal resource representation" was simply another oversight and not some ultra-clever means of . . . doing something (exactly what, I'm not sure). Absent any definition of what 'literal resource representation' might mean, we have to go back to the meaning of the word 'literal'. literal <http://dictionary.reference.com/search?q=literal> (adjective): 1. in accordance with, involving, or being the primary or strict meaning of the word or words: not figurative or metaphorical: /the literal meaning of the word/. 2. following the words of the original very closely and exactly: /a literal translation of Geothe/. 3. true to fact; not exaggerated; actual or factual: /a literal description of conditions/. 4. being actually such, without exaggeration or inaccuracy:/ the literal extermination of a city/ Given the above definition, it seems reasonable to fill in the missing definition with something like the following: *literal resource representation*: a representation of a resource unadorned by additional elements or attributes that are not a part of the actual representation. If it *were* true that "a literal resource representation can be anything the resource wishes it to be" I would expect to see a statement such as "Note, the term 'literal resource representation' does not convey any constraints on the form or content of the . . .", since the definition of the word 'literal' would lead people to conclude the opposite. - gp On 5/27/2009 4:02 PM, Geoff Bullen wrote: > > Doug, > > > > > 1 - this is no longer the literal representation, its now an instruction > > > > Can you please point to the definition of a literal resource > representation that is used as justification for this statement? > Otherwise the above statement simply represents your assumption of > what a literal resource representation may look like and your > assumption about what an instruction may look like. Basically, a > literal resource representation can be anything that the resource > wishes it to be, including a representation that has a consistent > outer element with the qname of "MyWrapper". > > It is not reasonable to insist that all resource representations MUST > (or even SHOULD) have a unique outer element qname, and certainly this > is never stated or implied anywhere. > > > > For example, what about resource representations of the form: > > > > <resource> <id>1</id> </resource> > > > > Surely this is a valid literal resource definition? > > > > Now s/resource/MyWrapper/g and then s/id/Resource/g -- and we get back > to my exact original example: > > > > <MyWrapper> <Resource>1</Resource> </MyWrapper> > > > > that you state above is an instruction and not a literal resource > definition. The only difference between these two examples is the > assumption of what each element's function is, which is implied from > the English names used. > > > > Does this make it clear why a literal resource definition can be > anything the resource wishes it to be? > > And why one man's instruction is another man's resource definition? > > > > Hope that helps, > > Geoff > > > > > > *From:* Doug Davis [mailto:dug@us.ibm.com] > *Sent:* Wednesday, May 27, 2009 2:12 PM > *To:* Geoff Bullen > *Cc:* public-ws-resource-access@w3.org > *Subject:* RE: Issue 6712 Discussion and Proposal > > > > > Geoff, > The spec says: > for create request: > The first child element, if present, MUST be the literal resource > representation... > for getResponse: > This REQUIRED element MUST have as its first child element, an > element that comprises the representation of the resource > > I think its fair to say that there is symmetry between these two > children chunks of XML. If the service requires some <MyWrapper> > element on the Create then there are several problems with this: > 1 - this is no longer the literal representation, its now an > instruction. Valid, but not my usecase. > 2 - this wrapper is not part of the Transfer spec and I'm looking to > support (as one half of my usecase) a vanilla transfer usage. So > requiring a non-Transfer wrapper element is not part of my use case. > 3 - the client _does_ need to know how to interpret this wrapper > because it needs to know that the service wants a wrapper to begin > with and how to use the wrapper. How does the client know that the > child of this wrapper is meant to contain the XML of the new resource? > It can't unless it knows how this element is meant to be used. Again, > we're no long in my usecase. > 4 - how does the client know this wrapper is needed? If the wsdl/xsd > offered by the service just shows wst:Create/xs:any then how did the > client know a wrapper is needed? It can't without some extension - > again, not my usecase. > > half of my usecase is that I want to support a vanilla Transfer for > interoperability - this means I want to limit myself to just what > transfer provides. I see no way to do what you're suggesting without > defining an extension. > > thanks > -Doug > ______________________________________________________ > STSM | Standards Architect | IBM Software Group > (919) 254-6905 | IBM 444-6905 | dug@us.ibm.com > The more I'm around some people, the more I like my dog. > > *Geoff Bullen <Geoff.Bullen@microsoft.com>* > > 05/27/2009 03:57 PM > > > > To > > > > Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org" > <public-ws-resource-access@w3.org> > > cc > > > > Subject > > > > RE: Issue 6712 Discussion and Proposal > > > > > > > > > > Hi Doug, > > > can you explain to me how the client will know how to interpret: > <MyWrapper> <Resource> ... definition... </Resource> </MyWrapper> > > Hmmm. Why does the client have to interpret this? This was an > example message that might be sent from the client to the service that > is doing the Transfer Create. The service has to understand it, not > the client. > > > when the spec, at least implies, that the non-instruction case will be: > <Resource> ... definition... </Resource> > > The spec shows an example that uses a similar format to that shown > above, but the spec neither defines or implies any format associated > with a resource. It is up to the resource itself to define this, not > the specification. Can you please point to the section in the > specification that even implies that there is some fixed format for > defining a resource? > > > It seems to me that your saying that base-Transfer (w/o extensions) > cannot support the use-case that it talks about (xml representation or > instruction). Is that true? > > As I have stated before, the base-Transfer spec (w/o) extensions can > easily support the use case it talks about (xml representation or > instruction). So the answer is no, your statement is not true. > > It seems you might be suggesting that there is a "standard" way to > define a resource and that to define a resource in any other way > should therefore be seen as an "extension". In reality there is no > standard way to define a resource, in the same way as there is no > standard way to define a set of instructions. These things are both > equally undefined, as it were. Since there is no standard, there can > be no concept of an extension. > > Hope this helps, > Geoff > > > *From:* public-ws-resource-access-request@w3.org > [mailto:public-ws-resource-access-request@w3.org] *On Behalf Of *Doug > Davis* > Sent:* Tuesday, May 26, 2009 2:08 PM* > To:* public-ws-resource-access@w3.org* > Subject:* RE: Issue 6712 Discussion and Proposal > > > Geoff, > can you explain to me how the client will know how to interpret: > <MyWrapper> <Resource> ... definition... </Resource> </MyWrapper> > > when the spec, at least implies, that the non-instruction case will be: > <Resource> ... definition... </Resource> > > It seems to me that your saying that base-Transfer (w/o extensions) > can not support the use-case that it talks about (xml representation > or instruction). Is that true? > > thanks > -Doug > ______________________________________________________ > STSM | Standards Architect | IBM Software Group > (919) 254-6905 | IBM 444-6905 | dug@us.ibm.com > The more I'm around some people, the more I like my dog. > > *Geoff Bullen <Geoff.Bullen@microsoft.com>* > > 05/07/2009 07:33 PM > > > > > > To > > > > Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org" > <public-ws-resource-access@w3.org> > > cc > > > > Subject > > > > RE: Issue 6712 Discussion and Proposal > > > > > > > > > > > > > > Doug, > > > 1) Create where I pass in the xml representation as a child of the > Create > > The spec uses the term "literal resource representation" > > > 2) an 'instruction based' Create where the QName of the Create tells > me the instruction > > Actually, the spec does not talk about QName's at all, nor what their > purpose is, this is just an implementation assumption that is being > made here. > > > 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. > > There seems to be an assumption being made here that the Transfer > specification in some way "defines" what the literal resource > representation (case #1) actually looks like, and that therefore, if > the first child element does not "conform" to this definition there is > an interop issue. It is our understanding that the literal resource > representation (case #1) can be any XML representation, and is service > specific (i.e. defined by the service), just as in case #2. Can you > please point to the normative language in Transfer that defines what a > literal resource representation should look like? Again, it is our > understanding that: > <Resource> ... definition... </Resource> > and > <MyWrapper> <Resource> ... definition... </Resource> </MyWrapper> > are both valid resource representations. Can you explain why the > second example is NOT a valid resource representation? > > > You're asking me to remove case #1 and make my implementation totally > non-interoperable. > > It is also unclear what is meant here by interoperable. Can you > please explain the scenario in which interop is broken? That would > help a great deal. If this is such a major interop issue, we are > surprised that Transfer has been implemented by so many and achieved > such a high level of interop to date. Perhaps there is a vital new > interop example that needs to be added to everyone's test cases? > > --Geoff > > * > From:* public-ws-resource-access-request@w3.org > [mailto:public-ws-resource-access-request@w3.org] *On Behalf Of *Doug > Davis* > Sent:* Thursday, May 07, 2009 6:20 AM* > To:* public-ws-resource-access@w3.org* > Subject:* RE: Issue 6712 Discussion and Proposal > > > 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 > 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 > > 05/06/2009 09:07 PM > > > > > > > > To > > > > 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 > The more I'm around some people, the more I like my dog. > > *Geoff Bullen <Geoff.Bullen@microsoft.com>* > > 05/06/2009 08:56 PM > > > > > > > > > > To > > > > Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org" > <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* > 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 > The more I'm around some people, the more I like my dog. > > *Geoff Bullen <Geoff.Bullen@microsoft.com>* > Sent by: 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" > <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* > 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 > The more I'm around some people, the more I like my dog. > > *Geoff Bullen <Geoff.Bullen@microsoft.com>* > > 05/06/2009 05:56 PM > > > > > > > > > > > > To > > > > Doug Davis/Raleigh/IBM@IBMUS > > cc > > > > "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 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; > 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 > > >
Received on Thursday, 28 May 2009 20:49:32 UTC