Comments on the sections:
* URIs used in Statements. Could you either unpack this section a little, or give an example? When reading in conjunction with the previous document, it seems that you're reusing identifiers incorrectly. I'm happy that the Edit-URI (URI of Atom Entry) is the Resource Map URI. This is as per the ORE/ATOM spec ( http://www.openarchives.org/ore/1.0/atom ) and should be in /entry/link[@rel=self] in the entry document. I'm less convinced that you can reuse EM-URI as the URI of the aggregation. EM-URI (and "almost always" Cont-URI) isn't a non information resource that represents the set of aggregated resources. >From Cont-URI you can "retrieve representations of the object as it resides in the SWORD server", making it a negotiable information resource? My understanding is that EM-URI / Cont-URI is the value of link[@rel="edit-media"] and Edit-URI is the value of link[@rel="edit"]? In RFC 5023, section 11, I think that the distinction is pretty clear that edit is to modify the entry (as you have) and edit-media is to modify an associated media resource (the actual content). Thus the re-use of it as the Aggregation URI seems very strange. The practical requirements for the URI of the aggregation are that it return a 303 status in response to a GET request, and a Content-Location of a Resource Map. In the default SWORD case this would only be the Atom Entry document, but that's perfectly acceptable as ConNeg could be used to get RDF serializations. Basically, I think you need a new URI here. * Content Negotiating for the Statement (moved in order) As above, you should ConNeg on the Aggregation URI to get a different mimetype for the resource map, not on the resource map URI. The Aggregation does a 303 redirect to the chosen serialization. Resource maps are not negotiable resources themselves. * Content Negotiating for Package Formats RFC2533 seems massive overkill, and very different from HTTP content negotiation. Could you set out the requirements that cannot be fulfilled by accept headers? My understanding is that the packaging format and the wrapped media format should be separately negotiable, but that can be handled with just a single new Accept- header that handles the wrapped data's format. [As the packaging is the outermost layer, it goes into Accept] If RFC2533 is the way you decide to go, then you should follow RFC2295 Section 6, which discusses a Accept-Features. Note in RFC 2616 (HTTP) defined after 2533/2295, it doesn't mention Accept-Features. However, 2295 defines a different syntax than 2533, and 2533 doesn't appear to officially update 2295. Transparent Content Negotiation from 2295 is very poorly implemented, and 2533 doesn't appear to be implemented at all. Basically, ... don't do it. Whatever the problem is, 2295 + 2533 is not the solution. * Obtaining Original Deposits Looks good to me. Is there also an atom link rel that could be used, or is it better to be in RDF? * Suppression of Metadata Handling I think the problem is more general, not just at the metadata level. What seems to be required is the ability to tell the server not to do any post-processing, just what was requested explicitly. This could extend to not indexing/unindexing the actual data, not updating feeds, and so forth. * Simplification of acceptPackaging Agree. If the client sends something that the server wants to reject ... it can just reject it. Can't this information be in the service description document anyway? * MD5 vs SHA1 Backwards compat seems more important than secure hashing. * Removal of userAgent Agree. * Package Formats in Deposit Receipt I'm not sure of the semantics here, but Atom semantics for extensions are so wishy-washy you're probably okay. It would be cleaner to define a slightly more structured extension: <sw:packages for="http://swordapp.org/server/100";> <sw:package>default</sw:package> <sw:package>MetsDspaceSip</sw:package> </sw:packages> And then the order of elements isn't important -- the information is self contained within the extension block. * Default Packaging, etc (URIs not Mimetypes) I know it's a pain, but until the rest of the world accepts that URIs for formats is the only sensible way to go, we're stuck with mime types. If those identifiers are to go into HTTP headers ever (as above), then I would recommend registering new mime types for them. * Content-Location header I would continue to omit. I think that client behavior when getting Location and Content-Location would be undefined, or at the very least unpredictable. HTH Rob > Hi Folks, > > Since writing the business case/technical design document, I have been > working on a detailed analysis of the spec's requirements based on that > document, the comments of this group, and the existing SWORD 1.3 > documents. I have enumerated a number of key points which represent > either decisions that I have provisionally made for the 2.0 version of > the spec, or questions that the group might have answers for or views > upon. > > Attached is a PDF containing those points, or it is available on google > docs here: > > https://docs.google.com/document/d/1uxJZBs7yJSoTvOb6-WqrM1d3ejfVB04mDLMs-n1w_Qg/edit?hl=en_GB&authkey=CMXJsIQL > > What I plan to do next is two-fold: > > 1/ I'd like to make some changes to the business case/technical document > to reflect discussion on this list and also on my findings in > investigating the way forward, and make that public as soon as possible. > > 2/ I'll be putting together some short internet draft style documents > for the various parts of the standard that we want to register with > IETF, with a view to getting those published and accepted into the > provisional register as soon as possible. > > In the mean time, your feedback on the attached document would be > invaluable. > > Cheers, > > Richard > >
