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

[Julie A. <ja...@yo...>]

Hi Jim, everyone,

First off, the new version of the profile looks great - better structure 
and clearer layout than the previous version, so should help with SWORD 
advocacy and uptake. 

It sounds like there's general agreement about most of your open 
issues.  Regarding the multi part question - I agree with Glen.  I'd 
like to see the SWORD profile extend beyond single files/packages.  
Also, we had earlier discussion about depositing by-reference - is there 
any support for that here? I'm not sure I see it. I had wondering about 
upping support for the deposit of ATOM documents, alongside the emphasis 
on 9.6.

Oh, and regarding backward compatibility - it sounds like most people 
are willing to sacrifice this for current simplicity and the SWORD 
implementation community is perhaps small enough to make that doable.

Can we agree a timescale for finalising this document please? - I'm sure 
the SWORD2 developers want to get implementing.  Can I suggest all 
comments by the end of Wednesday 10th September, with revised version 
soon after that?

Cheers,

Julie

Glen Robson wrote:
> 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
>


-- 
Julie Allinson  <ja...@yo...>
Digital Library Manager
University Library & Archives, J.B. Morrell Library
University of York, Heslington, York, YO10 5DD, UK
tel: ++44 (0) 1904 434083 skype: j.allinson
web: http://www.york.ac.uk/services/library/elibrary/digitallibrary.htm
--