Re: [sword-app-tech] SWORD 1.3

[Jim D. <oj...@ca...>]

Are there any more comments on this draft? I know Julie wanted to freeze
this asap.

Best regards,
jim

2008/9/10 Scott Yeadon <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
>>
>>
>>
>