Re: [sword-app-tech] [sword] Fwd: SWORD 1.3

[Glen R. <gle...@ll...>]

Hi all,

The document looks great. The only issue I want to bring up is the  
following from 5.4 and 9.3 :

SWORD implementations MAY implement the AtomPub mechanisms to edit

Should this be a SHOULD? I know we've discussed editing and deleting  
in the meeting in London and I can't see a need for delete but I can  
see the use cases for editing. Updating could also work for appending  
to a collection if the entry is a collection level document. What do  
others think? Will this cause problems with the workflow for deferred  
deposits?

Some other thoughts and votes below:

On 26 Aug 2008, at 16:10, Jim Downing wrote:

> Hi all,
>
> In this e-mail some open issues, and some reasoning where I've made  
> changes between 1.2 and 1.3.
>
> Open issues
>
> 1/ sword:formatNamespace and X-Formatnamespace aren't particularly  
> well named; sword:acceptPackaging X-Packaging seem more appropriate.  
> I erred on the side of not changing things.

Sounds a good idea to me

>
> 2/ It would be useful to have a user guide spelling out how to  
> implement "deferred" resource creation, i.e. where the server  
> responds 202 to the original POST.
>

as above

> 3/ How does the server obtain the identity of the client to use in  
> the atom:generator element? There's no header for it.
>

I agree with Stuart User-Agent HTTP header sounds good.

> 4/ I'm ambivalent about whether the error-codes should be in headers  
> or in a document. If we want to enforce back-compatibility the  
> headers will have to be supported in either case.
>

Both has got my vote.

> 5/ Adopting the multipart proposal would solve some issues (e.g. the  
> atom:generator issue above). It would mean a bit more complexity to  
> the authentication / mediation section. Also, it seems premature to  
> base SWORD on a draft RFC. Thoughts?
>

Will multipart allow the upload of a directory of files to a single  
deposit. If so I think this would be a useful addition as currently  
the only way to submit multiple files is to zip them up then deposit  
then.

> 6/ Pablo at MS requested a "preferred format" feature in the  
> collection element of the service document, or alternatively a  
> @preference attribute containing an ordinal number. Would others  
> find this useful?
>

I can see the use for this, you may prefer to work with the source  
format of a document but will take an access copy if supplied.


 > - sword:level: Can we just dump this requirement? AFAIK there are  
no real
 > production users of SWORD yet who couldn't easily change their  
tools, so
 > shall we drop it while we can? If we're not dropping it, most other  
service
 > documents in the spec are missing it.

I agree with Stuart if we can get away with removing it now it would  
simplify the spec as we now have sword:level and sword:version which  
may cause confusion.

Thanks

Glen