Hi Ian,
- Simplification of acceptPackaging: surely the list of what's not accepted is (in essence) infinite? The list of package types (even if they are defined by some Internet Taskforce) will grow over time. This NEEDS to be a "list of things I understand" - be they "I can give you in one of these formats" or "I can receive in one of these formats"... preferably each with a 'q'-weighting
The reason for the comment about not accepting formats was because the q value can be used to list formats the server will NOT accept, by setting q=0.0. This was the only thing that I could think that would cause any problems with removing the q value from acceptPackaging. Is anyone aware of anyone using SWORD who cares about the q values?
I agree with you, Ian, that this should be a list of "things that I understand", but the q value muddies this water a little by allowing it to also be a list containing "things I definitely don't understand".
- Recording Depositors and OnBehalfOf users: Could a client (well, a server) set a depositor or an OnBehalfOf value? Thought example: The Open Access Repository Junction Deposit Broker passes an item to repository "Foo". In that deposit is a statement defining that the item has come from Publisher "Bah". "Foo" accepts that deposit, however it has internally elected to have [virtual] Deposit-users to represent each of the publishers, therefore it sets the OnBehalfOf record to show it has been assigned to the depositor "Bah". Whether the Open Access Repository Junction Deposit Broker uses this information is moot - it is valid for "Foo" to state that it has defined the deposit as being OnBehalfOf "Bah"
Well, that's an interesting question. Obviously, the server is at liberty to do whatever it wants with the data when it's got hold of it, so something like you describe could happen. I think that this would be an implementation decision, though, rather than one for us to address during the spec.
- MD5 vs SHA1: I don't understand the context in full... as I understand it, Content-MD5 is a checksum for the content. Is there a significant issue in this checksum being spoofed? Ignoring the fact that the development for SWORD2 is coming from the Open Access Movement, is there a requirement for transfers to have a checksum that is "more secure" that any other? For 90-plus percent of situations, the difference between MD5 & SHA-1 is moot. The only issue that needs to be considered is "Backward Compatibility" - if we switch the checksum algorithm, then it will be more complex for systems to understand both SWORDv1 & SWORDv2 connections.
Agreed; thanks.
- Extracting Metadata from an Atom Entry: there are two thoughts here - 1) Why complicate the extraction process by having metadata in both me message carrier AND the payload?
I don't think this is what's suggested. The metadata is all in the Atom part, and presumed not to be in the payload when the default package format is specified.
2) How does the system deal with multiple authors? This seems to be a solution to a fairly specific problem, and one that is designed to make life easy for that problem, at the expense of the larger whole.
I'm not sure I understand. The metadata in the atom entry is no different than if the metadata were in the attached zip. This is simply our "default" package format, so that we don't have to have a long argument about which is SWORD's officially supported format. Instead we just take advantage of the standard that we are already employing.
- Content-Location header: Again, I'm not sure I fully understand this issue. "Location" is where the whole deposit can be found on the InterWeb (the abstract page, if you like.... <server>/<collection>/<deposit>) Is "Content-Location" a reference to recover the content... such as a script to extract the item (the Edit URI, I guess)
The atom spec I find a little confusing on the matter, hence the question and suggestion to continue to omit it :) I believe the answer is to continue to omit it!
Cheers, Richard
