Re: [sword-app-tech] SWORD 1.3

[Scott Y. <sco...@an...>]

Hi Jim,

Re the open issue, I agree with addition of a new element rather than 
redefine use of atom:source.

1.1
typo: "numberic"

1.3/1.4
Does the server need to regurgitate the package type back to the client 
given the client is the one to specify this in the first place?  I'm not 
sure I understand the context of this. The server response I would think 
is likely only to hold that information which the client needs to know 
post-deposit (e.g. identifiers of created objects, links to created 
objects, metadata allowing the client to map internal information to 
repository versions of objects, etc). There's nothing wrong in the 
example, I'm just not sure why this would be needed. In our journal 
example, we would only need to provide a response to OJS in order it can 
keep an audit trail as well as link to repository versions of a journal 
issue and its articles, for example see

I still think some examples of complex object deposits would be useful 
however the statement in 9.8 regarding atom:content I think puts this 
out of scope for the 1.3 spec. Maybe these are better in an 
implementation guide that perhaps could be drafted as part of the 
eprints/Fedora/DSpace implementation deliverables?


 From an implementation point of view, I think it's important for any 
server implementation to be able to make Service Document and Deposit 
Responses pluggable/configurable. In real-world implementations this is 
going to be needed as there will be great variation across client 
application requirements and package-to-data-model mapping in repository 
deposit targets. For example, in DSpace it may be possible to 
instantiate different SWORD service document- and deposit response- 
handler classes based on a combination of Package Ingester 
configurations and User-Agents (or something like that) allowing for 
context-based deposits.

Scott.
> Message: 6
> Date: Tue, 9 Sep 2008 09:17:12 +0100
> From: "Jim Downing" <oj...@ca...>
> Subject: [sword-app-tech] Fwd: SWORD 1.3
> To: swo...@li...
> Message-ID:
>     <2ab...@ma...>
> Content-Type: text/plain; charset="utf-8"
>
> Hi all,
>
> A second draft of the SWORD revision 1.3 is available at
> http://sword-app.sourceforge.net/sword-1.3/sword-profile-1.3.html.  A
> summary of the changes since the first draft: -
>
> * typso fixed
> * formatNamespace renamed
> * A potential mechanism for preferred packaging added
> * Error documents replace X-Error-Code. I was unhappy about returning an
> atom:entry in precisely the situation where one isn't created, so error
> documents are rooted at a new element.
> * More explanation of the service nesting mechanism.
>
> Some of these changes break compatibility with 1.2.
>
> Open Issue:
> * We can either overload atom:source to contain the User-Agent, or else
> invent a new element to contain the information. Given the choice I'd 
> prefer
> the latter, what does everyone else think?
>
> Best regards,
> jim
>
>