- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Fri, 19 Apr 2013 15:41:22 +0100
- To: David Wood <david@3roundstones.com>
- CC: public-ldp-wg@w3.org
On 19/04/13 14:25, David Wood wrote: > On Apr 19, 2013, at 09:21, Andy Seaborne <andy.seaborne@epimorphics.com> wrote: >> >> On 19/04/13 07:01, Henry Story wrote: >>> >>> On 18 Apr 2013, at 23:51, Arnaud Le Hors <lehors@us.ibm.com >>> <mailto:lehors@us.ibm.com>> wrote: >>> >>>> All the spec currently says on this is: >>>> >>>> 4.4.6 LDPR servers /MAY/ choose to allow the creation of new resources >>>> using HTTP PUT. >>>> >>>> Which I read as trying to discourage this practice although it's not >>>> quite that clear. What you're describing only makes me want to add >>>> something like the following to reinforce that thought! :-) >>>> >>>> LDPR clients SHOULD NOT try to create new resources using HTTP PUT. >>> >>> >>> +1 >> >> -1 >> >> Example 1: >> >> A container of colors. >> >> I want to add an entry for "black" and I want the name to >> be /colors/black. >> >> PUTting to /colors/black and then linking seems a natural way to do that. >> >> I don't want container generated names - I want to control the name. > > > How is this different from POSTing to container /colors/ with a Slug of 'black'? Generally: the suggestion was to advise strongly again using PUT to create. But that's a natural use of HTTP. We seem to be creating a general framework in abstract discussion, and then rolling that that back over existing patterns. So why is PUT to create bad whereas PUT to replace is good? On 18/04/13 22:23, Wilde, Erik wrote: > yes. supporting unconstrained PUT (PUT into the universe of all > possible URIs) doesn't make a whole lot of sense. supporting PUT into > some constrained URI space may make sense, but that space needs to be > defined somehow, at least in a way that a client has a reasonable > chance to come up with a URI that will actually work. On 17/04/13 11:38, Eric Prud'hommeaux wrote:> If the client knows or has control over the name of the resource to be > created, it should PUT the contents to the new location. There are > several problems with this caveat: (then Eric has a list of two things for one caveat :-) The space is everything under http://host/colors/ -- it's delegating that space of names and security stops any other role messing with that. Documentation, if nothing else, tells you the scope of URIs. Specifically: In Atom, "Slug:" is a hint. Common usage is to uniquify the generated name and works well for the blogging case but that's not what this is. http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0028.html (RFC 5023, section 9.7) > If the server respects the slug, you get what you want. If it doesn't, you were never going to get the URL you desire anyway. An indication of rejection is better than 200 and mutating the URI. Are we limiting LDPR's to ALWAYS be in exactly one container? I suppose with no standardized ability to link, it's less of an issue for V1. Andy > > Regards, > Dave > -- > http://about.me/david_wood > > >> >> Because next I want to create a special entry "black400" for "400% Registration Black" (which is used in commercial printing). But as a general container for colors, there is no need to encode knowledge of commercial printing naming. >> >> Example 2: >> >> The WMO (World Meteorological Organisation) publishes code lists, currently as books and PDFs maybe soon as linked data. The code items exist and the names are fixed. Client-side control of URI is very important to them. >> >> /0-20-086/6 is the code for "slush" >> >> /C-6/001 is the code for the unit "meters" ... and it must be 001, not 1. >> >> Andy >> >
Received on Friday, 19 April 2013 14:42:00 UTC