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.