On Tue, 2011-06-28 at 12:12 -0500, Kathi Fletcher wrote:
> I am curious whether clients are allowed to reuse URL's that they
> receive for collections in the service document or for
> edit/edit-media/sword-edit URL's from the deposit receipts?
...
> Lets say you ask for a service document, and I give you a collection
> URL and you post a new deposit. Will the client ask for the service
> document again before posting a second package? Will my service be
> able to give you out a new URL for that same collection to receive a
> second deposit?
This is an area that is confusing and is part of the reason why the
first rendition of SWORD focussed on the initial deposit
('fire-and-forget').
SWORD v2 has been concerned with what happens next - how to append, how
to replace or delete uploaded content, and how to remove entire
containers of content. If your service is going to let a client do
anything past the aforementioned fire-and-forget, then you should look
at SWORD v2.
So to break down your scenario: (s - server, c - client)
c: GET /service-document
s: returns "service-document.xml"
client picks a collection to upload something to, say "Coll-IRI"
c: POST Coll-IRI .... [w/ uploaded file/pkg]
s: returns a Deposit Receipt
The receipt is important in your scenario - it should contain a variety
of URIs with which you can further interact with your upload.
Deposit Receipt in SWORD v2
http://sword-app.svn.sourceforge.net/viewvc/sword-app/spec/trunk/SWORDProfile.html?revision=HEAD#depositreceipt
It MUST contain an Edit-IRI, an Edit-Media-IRI and a SWORD-Edit-IRI.
Each of these have a use and should be specific to your upload. To
append a package or file to the items you've uploaded, you would POST to
the SWORD-Edit-IRI[1] or to add a single file, you would POST to the
Edit-Media-IRI[2], and to replace content, you would PUT to the
Edit-Media-IRI[3] for example.
1- http://bit.ly/jKMGpC
2- http://bit.ly/iprgTr
3- http://bit.ly/mfQyl6
It is expected that the Coll-IRI will remain the same however - a
different Coll-IRI by definition is a different collection, regardless
of how your service logically labels it (ie via a dc:title or similar)
I am curious as to why the need for creating a new Collection URI per
deposit has arisen - can you give any context as to why?
>
>
> And similarly, if you post a package and get back the Edit-Media URI
> from the deposit receipt and then decide to add two images to the
> deposit. Will clients try to POST the two images both to the same URI,
> or will they post the first image to the original Edit-Media URI, get
> the deposit receipt (with potentially a new Edit-Media URI) and post
> the second image to the Edit-Media-URI from the receipt from the first
> image's post?
>
Under SWORD v2, it is expected that if the images are POSTed to the
EM-URI, each upload should have a response from the server, with the
HTTP header 'Location' set to the URI of the image just uploaded. The
Edit-Media-URI will be the same on both uploads, as this is the
'content' of the deposit container identified by the Edit-URI.
(NB I am still working through the SWORD2 spec so I might have
misinterpreted something. Hopefully, any mistakes will be highlighted by
subsequent posters!)
Ben
>
> Kathi
>
> --
> Katherine Fletcher, kathi.fletc...@gmail.com
> Twitter: kefletcher Blog: kefletcher.blogspot.com
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________ sword-app-tech mailing list
> sword-app-tech@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sword-app-tech
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
sword-app-tech mailing list
sword-app-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sword-app-tech
