RE: [Bug 6712] Transfer: Create is ambiguous

Since the spec doesn't actually say what you claim it says, I believe my 
interpretation is valid and correct. And the text you quoted actually 
leads me to believe that multiple constructors is exactly what they were 
talking about.  For example, looking at WS-Eventing's Expires element it 
allows for more than one content type - using similar "or" text - and that 
spec doesn't forces either side of the message exchange to choose to 
support only and exactly one content type for that element.  It can 
dynamically determine this at runtime based on what's in the message.  So, 
these are all valid:
  myResource(xs:any)
  myResource(EPR-to-copy-from)  (using an example you previous mentioned)
  myResource(Fragment-of-resource)
What's missing is the ability for the service to distinguish between the 
xs:any variant and the other two (in the case where the resource is 
defined as an xs:any).  However, and this came me to last night while 
trying to sleep on a red-eye so it might not be fully baked, what I think 
we might need is not so much a "Dialect" as much as a "boolean" that tells 
the receiver whether the content is the representation or instructions. 
Once we know its an instruction we don't need a Dialect URI to tell us 
what to do - the QName of the child should tell us that.  So perhaps 
something more along the lines of:
<wst:Create interpret="xs:boolean"?>
  xs:any*
</wst:Create>
where the default value of "interpret" is 'false'.

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> 
04/21/2009 12:56 AM

To
Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org" 
<public-ws-resource-access@w3.org>
cc

Subject
RE: [Bug 6712] Transfer: Create is ambiguous






Doug,
The spec says ?The contents of this element are service-specific, and MAY 
contain the literal initial resource representation, a representation of 
the constructor for the resource, or other instructions for creating the 
resource.?
You are interpreting the spec to say that it can contain more than one of 
these things for a given resource.  We believe the spec is saying that the 
contents are server-specific and can contain either the literal 
representation, a representation of the constructor for the resource, or 
other instructions for creating the resource.  The resource must choose 
what representation it expects.  There is nothing to say that a particular 
resource supports more than one representation.
Cheers,
Geoff
 
 
From: public-ws-resource-access-request@w3.org 
[mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Monday, April 20, 2009 4:48 PM
To: public-ws-resource-access@w3.org
Subject: Re: [Bug 6712] Transfer: Create is ambiguous
 

Geoff, 
  the transfer spec allows for either the XML representation or a list of 
instructions.  If I have a resource that is defined as an xs:any _and_ it 
allows instructions, how, as a service do I know which is being passed in? 
 

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 
04/20/2009 07:33 PM 


To
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org> 
cc

Subject
[Bug 6712] Transfer: Create is ambiguous
 








Since this issue (6712) seems to be increasing in importance, based on its 
relevance to Issue 6413, I suggest that we look at this issue sooner, 
rather than later.  To that end I would like to start some discussion 
around it.

Our understanding of the current Transfer Spec, concerning this issue, is 
that the interpretation of the contents of the first child of the Create 
message is defined by the resource to which the create message is 
addressed.  Thus the resource itself defines if the message contents 
represents the contents of the resource or some instructions about how to 
create it.  This matches the semantics of HTTP POST.  It seems from the 
issue text that Doug is implying that the client has some control and 
should be able to dictate to the resource what is in the contents of the 
create message.  We do not see anything in the current spec or any 
existing implementation that supports this notion, nor do we see any other 
verb in the Transfer Spec that supports this.

We also believe that it is already clear how to extend the Transfer spec 
to allow concepts such as client control by using optional elements added 
to the body and then a "mustUnderstand" element to the header, as it done 
for in other specs.

As an initial proposal here, I suggest we work up some wording changes to 
clarify the text around Create so that it is clear that it is the Resource 
that defines what type of information is required in the Create message. 
We would be willing to prepare such text, if this proposal is acceptable 
to the WG.

--Geoff

-----Original Message-----
From: public-ws-resource-access-notifications-request@w3.org 
[mailto:public-ws-resource-access-notifications-request@w3.org] On Behalf 
Of bugzilla@wiggum.w3.org
Sent: Wednesday, March 18, 2009 4:37 AM
To: public-ws-resource-access-notifications@w3.org
Subject: [Bug 6712] Transfer: Create is ambiguous

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6712


Robert Freund <bob@freunds.com> changed:

          What    |Removed                     |Added
----------------------------------------------------------------------------
        AssignedTo|public-ws-resource-access-  |dug@us.ibm.com
                  |notifications@w3.org        |
          Keywords|                            |hasProposal




-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.