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

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

Hi Glen,

Thanks for your comments.

2008/9/4 Glen Robson <gle...@ll...>

> 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?


I'm open to it being a SHOULD. It would bring SWORD closer to AtomPub which
is a good thing.

When it comes to incremental update, the way I see it being done is that on
the original POST, the server creates a new AtomPub (or AtomPub/SWORD)
Collection, and that you update by POSTing new resources to that. The reason
I haven't put this in SWORD is that it's something that can be done without
any extensions to AtomPub. I think it would be worth a user guide
demonstrating how one might create an AtomPub collection as the result of a
SWORD POST. I'm not sure it needs to be in the spec though.


> Some other thoughts and votes below:
>
> On 26 Aug 2008, at 16:10, Jim Downing wrote:
>
> > 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.


The multipart RFC as it stands just allows an Atom entry to be sent along
with the same kind of payload as current Media Resource POSTs. So "no" in a
word!

Best regards,

jim