- 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