On 17/01/11 19:27, Richard Jones wrote:
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.
1) Help ma poor wee head..... that was certainly not a LadyBird Books
reading :)
2) Some comments:
- 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
- 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"
- 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.
- 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?
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.
- 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)
--
Ian Stuart.
Developer: Open Access Repository Junction and OpenDepot.org
Bibliographics and Multimedia Service Delivery team,
EDINA,
The University of Edinburgh.
http://edina.ac.uk/
This email was sent via the University of Edinburgh.
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
