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 13:48:28 -0700
Message-ID: <4A1EF89C.2030607@oracle.com>
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>
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 GMT

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