On Wed, Mar 16, 2011 at 10:52:27PM +0000, Richard Jones wrote: > > 6.5. Deleting the Content of a Resource > > > > Should return the 200 header representing what has happened. > > > > I'm against the delete operation on the content URI returning the receipt > > of the edit-URI. > > No one asked for this, the client asked for the thing to be deleted, not a > > statement or > > receipt! I've made this point before... it got ignored. > > Oh for god's sake Dave, grow up. It did not get ignored because you and > I had a long discussion about it in person. I argued that since all the > other operations can optionally supply a response to a DELETE request, > it was inconsistent to not be able to supply one in this one instance. > Additionally, the deposit receipt is strictly optional in ALL cases as > per the specification. You argued that DELETE doesn't allow a response > (and should return 204), and this turned out to be untrue when I pointed > you to the HTTP spec. I'd appreciate it if you'd actually remember the > discussions we've had about this before having a strop.
FWIW, in our data repository implementations, some collections use Atom tombstones [1,2], and some don't. For collections that use tombstones, a DELETE request will return a 200 with an at:deleted-entry as the response body. For collections that do not use tombstones, a DELETE request will return 204. So I believe it is reasonable to return some content in response to a DELETE request. Whether you should or not will depend on what the client needs. I remember seeing some ideas around clients being able to express a preference for 204 or 200 in response to DELETE, but I don't know if that went anywhere. Cheers, Alistair [1] http://tools.ietf.org/html/draft-snell-atompub-tombstones-12 [2] http://code.google.com/p/atombeat/wiki/TombstonesDesign - ignore the stuff about ghosts, that's probably going to change > > > The client knows the edit-URI as as you say in your video Richard, if you > > do a get on the > > Edit-URI you can get the receipt again. This is too overblown here. > > It's strictly optional as per the document. If you don't want to return > a receipt in your implementation, then don't. > > > 1) Client asks to delete object at any URI > > 2) Server returns http error code > > > > If the server chooses to return anything else then the Content-Location > > header MUST be > > used to define what it is returning. This is because the client SHOULDN'T > > be able to call > > the same delete operation to get the same content as the object should 404 > > or 410 at > > that point. > > I will add the requirements on the Content-Location header to the spec > if that's the appropriate thing to do. I'm still a little unsure about > how Location and Content-Location should be used ... have to go do some > more reading of the HTTP spec. > > > 6.6. Adding Content to a Resource > > > > Yuck! This section needs completely re-writing and/or removing. There is no > > detail > > here on what the server should do with the random content it is given and > > where it should go. > > If it is posted to the Edit-URI, is the a new EM-URI, replace everything at > > the EM-URI or > > what. I think if you want to add content (Media) into the container then > > you post it to the > > Edit-Media URI. > > POST to the EM-URI implies something about the structure of the Media on > the server. POST to the Edit-URI is the appropriate RESTful way to add > new content to a container. > > There is no detail on what the server should do because SWORD is an > interface definition not a set of implementation decisions. How the > server implements a POST of new content to the container is up to the > precise mechanisms of the application ... > > > I really don't like this and think we should more closely consider GDocs > > API here for > > how to handle containers and the limitations. > > We have tried to ensure that the GData spec is not ruled out by SWORD, > but it brings with it its own set of idioms with regard to hierarchical > file systems which may be appropriate for EPrints, but is not > necessarily appropriate for all other scholarly information systems. As > such, I'm reticent to propose it as /part/ of SWORD but I do want to > ensure that you can implement it /as well as/ SWORD. > > I spent some time working through the GData 3.0 spec and was unable to > find any information about exactly how they think you should get hold of > the feed representation of an entry. I have assumed content negotiation > on the Edit-URI (see Section 6.8), but if you could confirm for me how > Google recommend this is done that would be useful. > > > This whole fudge it and see it not going to help in the future. > > this doesn't appear to be a sentence. can you reword/expand? > > > Interestingly section 6.6.3 DOES use the EM-URI not the Edit-URI...? Any > > reason? > > Typo, by the looks of it, I will fix that. > > > Other than that, this looks pretty good. I still believe it can be made > > much better > > through better alignment with the GDocs API, this will also make it simpler > > for both > > the server and client while enabling more functionality. I am going to > > change a > > version of this spec to reflect this and then people can see the main > > differences > > and capabilities. This also may rid the need for the statement URI and make > > it > > simpler again. > > I strongly feel that you are too focussed on the EPrints implementation > decisions where the GData API may be appropriate. We have try, with > SWORD, to avoid getting bogged down in the details of the structure of > information at either end of the protocol. We are purely concerned with > deposit, not with content management, as we discussed early on. > > As detailed in the spec, the statement URI can indeed be the same as the > URI which retrieves the feed representing the entry as employed by > google docs. > > Cheers, > > Richard > > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Sword-app-techadvisorypanel mailing list > Sword-app-techadvisorypanel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel -- Alistair Miles Head of Epidemiological Informatics Centre for Genomics and Global Health <http://cggh.org> The Wellcome Trust Centre for Human Genetics Roosevelt Drive Oxford OX3 7BN United Kingdom Web: http://purl.org/net/aliman Email: aliman...@gmail.com Tel: +44 (0)1865 287669 ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Sword-app-techadvisorypanel mailing list Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
