RE: Issue 6712 Discussion and Proposal

The service works with any XML - think of it as font-ending a DB entry for 
a blob.

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/28/2009 07:01 PM

To
Doug Davis/Raleigh/IBM@IBMUS
cc
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Subject
RE: Issue 6712 Discussion and Proposal






Thanks Doug,
The first part here is still a little unclear, so a few more questions are 
necessary, if I may, to try to clarify what exactly is going on:
1)      The service in part 1 wants to work with a client that thinks the 
Create message is just an xs:any ? correct?
2)      Does the service in part 1 accept every conceivable XML string and 
then do something useful with it? If so, what is the purpose of the 
service and what is the client expecting this generic service to do with 
these totally random XML strings?
3)      If the service in part 1 actually only accepts certain XML strings 
(as is the normal case), how does the client know what strings can be 
sent?  (Normally this might be done through some out of band 
communications ? like the valid resource formats are specified in a 
document).
Thanks again,
Geoff
 
From: Doug Davis [mailto:dug@us.ibm.com] 
Sent: Thursday, May 28, 2009 3:29 PM
To: Geoff Bullen
Cc: public-ws-resource-access@w3.org
Subject: RE: Issue 6712 Discussion and Proposal
 

Geoff, 
  as I've stated several times, my usecase has 2 parts.  First is the 
"interoperable" half - this part involves a service wanting to work with 
any generic Transfer client that only knows about what's in the Transfer 
spec. And in this case the client would only know to send the resource 
(unwrapped) in the Create and it would expect back that same XML in the 
GetResponse.  If we can't agree on this behavior then Transfer is totally 
broken and we have bigger fish to fry.  For this half of the usecase 
requiring any kind of wrapper would be a non-interopable solution - so you 
continually insisting that the service require a wrapper is not acceptable 
because doing so would require an extension (to define this wrapper) and 
breaks my usecase of a generic Transfer client working with this service. 
  The 2nd half of my usecase involves the service wanting to support 
advanced clients who know about the services 'special' extensions - 
meaning they know about the service-specific instructions that the 
Transfer spec says are allowed to be placed in the Create. In these 
situations as a service I have no way of knowing whether or not the child 
element is an instruction or part of the resource.  Or said another way, 
the service doesn't know which half of the usecase is being invoked. 
  My proposal allows for a clear, unambiguous, interoperable way for this 
information to be conveyed.  None of your proposals meet the requirements 
of this usecase and changing the usecase is not an acceptable solution. 

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/28/2009 06:08 PM 


To
Doug Davis/Raleigh/IBM@IBMUS 
cc
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org> 
Subject
RE: Issue 6712 Discussion and Proposal
 








Thanks Doug, 
So your use case is a Service that wants to accept absolutely any XML 
given to it and will use that XML as the literal resource definition of 
the resource.  The service also wants to accept instructions.  Not sure 
what kind of service this might be, but it seems certainly a real edge 
case rather than the norm. 
So, using the current spec as it stands, the service could just put an 
element around the outside so that it can distinguish between resources 
and instructions: 
<resource> xs:any </resource> 
<instruction>xs:any</instruction> 
A Transfer Get could also return <resource> xs:any </resource>. 
Now as I understand it, you think doing this is a very bad thing to do, 
because we have added a ?wrapper? to things.  But that is only an opinion. 
 The Service may actually store the resource element as a valuable part of 
the resource definition, based on the fact that it might also store the 
instruction element and the instructions as well.  In that case the 
definition of the resource actually includes the fact that it is a 
resource, and that seems a perfectly reasonable approach to this problem. 
  
In the normal usage scenario, the Create would only accept a few outer 
elements (probably one) as the representation of the resource.  So it 
seems a logical extension to have an ?anything? resource under an 
?anything? element. 
  
From: Doug Davis [mailto:dug@us.ibm.com] 
Sent: Wednesday, May 27, 2009 4:58 PM
To: Geoff Bullen
Cc: public-ws-resource-access@w3.org
Subject: RE: Issue 6712 Discussion and Proposal 
  

No.  the service allows anything - an xs:any.  So its the client that 
decided its <x:foo/> 

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 07:56 PM 
 


To
Doug Davis/Raleigh/IBM@IBMUS 
cc
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org> 
Subject
RE: Issue 6712 Discussion and Proposal

 
 









Hi Doug, 
Ok, let?s do this one step at a time. 
 
Who specified that the resource should be defined as <x:foo/> ?  I assume 
the service defined this, right? 
So how did the client know that it should send <x:foo/> in the Create 
message to the service? 
 
 
From: Doug Davis [mailto:dug@us.ibm.com] 
Sent: Wednesday, May 27, 2009 4:43 PM
To: Geoff Bullen
Cc: public-ws-resource-access@w3.org
Subject: RE: Issue 6712 Discussion and Proposal 
 

Geoff, 
per my usecase, the service allows an xs:any for the resource.  Therefore, 
in a vanilla WS-Transfer if my resource looks like: 
<x:foo/> 
then the create needs to look like: 
<Create> 
<x:foo/> 
</Create> 

If I were to add any kind of wrapper then that wrapper would be included 
as part of the "literal resource representation".  I quoted this from the 
spec already  - see below. 
Please show me where in the Transfer spec it says that it can be done any 
other way.  And, how that "other way" is known to the client? 

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 07:02 PM 
 
 


To
Doug Davis/Raleigh/IBM@IBMUS 
cc
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org> 
Subject
RE: Issue 6712 Discussion and Proposal


 
 
 









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
The more I'm around some people, the more I like my dog. 

Geoff Bullen <Geoff.Bullen@microsoft.com> 
05/06/2009 10:39 AM 
 
 
 
 
 
 
 
 


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


 
 
 
 
 
 
 
 
 










> 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] 
Sent: Tuesday, May 05, 2009 3:11 PM
To: Geoff Bullen
Cc: public-ws-resource-access@w3.org; 
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
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/05/2009 01:05 PM 
 
 
 
 
 
 
 
 
 


To
"public-ws-resource-access@w3.org" <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:12 UTC