- From: Gilbert Pilz <gilbert.pilz@oracle.com>
- Date: Thu, 28 May 2009 16:12:17 -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: <4A1F1A51.9070801@oracle.com>
Geoff,
I used the phrase "something like" to indicate that my definition was
cursory and incomplete. I suspect the final definition will require a
specific rule such as "if you Create {this} then a Get on
/wst:CreateResponse/wst:ResourceCreated will return {that}", where
{this} and {that} are 'equivalent XML' (baring whitespace changes etc.)."
The answer to all your examples lies in what the client gets back when
it does a Get on the newly created resource.
I'm curious as to whether you think there is any particular purpose to
leaving the definition of "literal resource representation" vague, or
whether you are claiming that "that's just the way it is"?
- gp
On 5/28/2009 2:24 PM, Geoff Bullen wrote:
>
> Hi Gil,
>
> While I really do not want to get into a long discussion about this...
>
>
>
> > 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.
>
>
>
> Who decides what is an adornment and what is not?
>
> Will there be some kind of standards committee set up to oversee the
> correct definition of all resources and the adornment police to track
> down violators? J
>
>
>
> For example, if we were to appoint you as a captain in the adornment
> police (congratulations btw), which of these XML strings are literal
> resource definitions and which ones aren't and why?
>
> a) <host> <name>fred</name> </host>
>
> b) <resource> <host name="fred"/> </resource>
>
> c) <wrapper> <item name="fred"/> </wrapper>
>
> d) <resource> <host> <name>fred</name> </host></resource>
>
> e) <resource>
> <class>host</class><address>1.2.3.4</address></resource>
>
> f) <rule> <resource> must be a literal definition</resource></rule>
>
>
>
> *From:* Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
> *Sent:* Thursday, May 28, 2009 1:48 PM
> *To:* Geoff Bullen
> *Cc:* Doug Davis; public-ws-resource-access@w3.org
> *Subject:* Re: Issue 6712 Discussion and Proposal
>
>
>
> 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
> <mailto: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 <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/27/2009 03:57 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
>
>
>
>
>
>
>
>
>
> 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>
> [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
> <mailto: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 <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/07/2009 07:33 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,
>
> > 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>
> [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
> <mailto: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 <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>
> [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>
> [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
>
>
>
Received on Thursday, 28 May 2009 23:13:11 UTC