Hi Dave, >>> 6.4. Editing the Content of a Resource >>> >>> The client MAY provide an In-Progress header with a value of true or false >>> [SWORD001] >> >>> 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. > > Both of these are in fact about which URI you are interacting with not what > is returned. > If you are CRUD'ing to one URI the server should never return data which is > not related to > that URI without some sort of 300 redirect.
I see what you're saying. It looks like this is also legitimate if a Content-Location header is provided, if I am interpreting the HTTP spec correctly (which is maybe not the case). > So the response of the DELETE should always be relevant to the URI you have > just deleted. So, I guess I'd want to clarify what "relevant" means here. I can't find anything definitive in the HTTP spec which tells you how what you get back from the DELETE request should be related to the resource deleted. Any references you have that I could look at? > The In-Progress header should refer only to the URI which it is related to, > since In-Progress > (or status) is in fact a piece of metadata i'd recommend moving it to the > atom metadata and > turning it into a category. Thus you move the item through a workflow by > changing the metadata. > > Neither of these are EPrints specific, just general good practise of a web > server :) I agree that the In Progress header should only be supplied on the container. In the next version of the profile I'll make that change. In the mean time, though, once again: this exists as a header because when you are POSTing a ZIP file without an Atom Entry before it, there is no Atom Entry for a sword:inprogress element to be placed in. Also, it's not the business of SWORD to be moving things through the workflow - that would be either a content management operation or some other class of administrative interface, which would be out of legitimate scope. In Progress is intended purely to hint to the server that it might expect more content to be coming before the client considers the full deposit process finished. >>> 6.6. Adding Content to a Resource > > I'll get onto this and point, just as a pointer however look at the 'Creating > a folder' section in the GDocs API. I've been through the GDocs API, and believe that we've included enough in the SWORD spec to ensure that it's use is not prevented (to the point of being explicitly mentioned). Also, I looked in the GData 3.0 spec for information on how to retrieve the feed of an object, rather than an entry, and it didn't say. I presumed content negotiation (hence section 6.8 of the sword profile), but perhaps you know where there's a formal definition of how this bit works - the GData documentation did seem a little bit all over the place? I'll include some more details in the next version as to how to use SWORD extensions on any old URI, and that should hopefully be enough to combine it fully with GData. See my other email about the scope of sword, and let me know what you think. Cheers, Richard ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Sword-app-techadvisorypanel mailing list Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
