I agree totally with Graham here. Paragraph 2 of impact summed it up for me.
“This next version of SWORD will instead constrain itself to a single critically important area which will pave the way to full deposit lifecycle support: the URIs supplied to the client in the deposit receipt, and the resources to which they resolve.”
It should pave the way, people should be able to use the returned URI to do the REST (pardon the pub) in whatever way they choose – have I mentioned I’m advocating HTTP GET and ACCPET headers?. Thus this diagram should just be, client upload (as many times as they want as you should be able to PUT to a URI to replace something) and the receipt contains the URI of the successfull compleation.
All the REST should be left to… well REST which can be different for every system (cos it will be).
I think there’s a danger here that SWORD starts to look big and complicated, losing some of the original appeal of its simplicity as a thin layer over AtomPub. Maybe that’s unavoidable, but it would be a shame if there’s no easy-to-implement route in.
I agree totally with Graham here. Paragraph 2 of impact summed it up for me.
“This next version of SWORD will instead constrain itself to a single critically important area which will pave the way to full deposit lifecycle support: the URIs supplied to the client in the deposit receipt, and the resources to which they resolve.”
It should pave the way, people should be able to use the returned URI to do the REST (pardon the pub) in whatever way they choose – have I mentioned I’m advocating HTTP GET and ACCPET headers?. Thus this diagram should just be, client upload (as many times as they want as you should be able to PUT to a URI to replace something) and the receipt contains the URI of the successfull compleation.
All the REST should be left to… well REST which can be different for every system (cos it will be).
I think there’s a danger here that SWORD starts to look big and complicated, losing some of the original appeal of its simplicity as a thin layer over AtomPub. Maybe that’s unavoidable, but it would be a shame if there’s no easy-to-implement route in.