Hi Richard, I just had a skim of the SWORDProfile spec in SVN [1], I'm guessing this is the one you're working on?
I had a couple of thoughts, this is the first time I've seen the proposals for SWORD v2, and haven't been involved in any previous discussions, so apologies if you've been through this already. Also apologies if I missed something in the spec, I didn't go through it yet with a fine comb. I notice in the current spec you overload the 'edit-media' relation to define new protocol behaviour when POSTing binary content to a deposit's edit-media URI. I wonder if an alternative pattern might give you a bit more flexibility, and be a bit easier to implement, without having to define any new protocol behaviour. Let's assume you've done a GET on the service document URI and chosen a collection URI to work with already. As described in the spec, you then create a new deposit by POSTing some packaged binary content to the collection URI. In return you get a 201 with an Atom entry document. The returned Atom entry document has an "edit" link and an "edit-media" link as usual, and also a new link - let's call it "package-contents" for now, what it's called doesn't really matter for this email, it's the pattern I'd like to focus on. E.g.: <entry xmlns="http://www.w3.org/2005/Atom";> <title>al's first deposit</title> ... <link rel="edit" type="application/atom+xml;type=entry" href="http://example.org/deposit/foo.atom"/> <link rel="edit-media" type="application/zip" href="http://example.org/deposit/foo.media"/> <link rel="package-contents" type="application/atom+xml;type=feed" href="http://example.org/unpacked/foo"/> ... </entry> If you want to update (replace) the entire packaged content for this deposit, you would do a PUT on the edit-media URI as per standard Atom protocol. If you want to update (replace) the metadata for this deposit, you would do a PUT on the edia URI, again as per standard Atom protocol. Now, what's implicit here is that, as a side-effect of the initial POST request to create the deposit, the server will have unpacked the packaged content, and is now exposing the unpacked media resources as a standard Atom collection, which is discoverable via the "package-contents" link. I.e., if you were to do a GET on the package-contents link URI, the server would return an Atom feed listing all of the media resources within the package. E.g.: <feed xmlns="http://www.w3.org/2005/Atom";> ... <link rel="self" type="application/atom+xml;type=entry" href="http://example.org/unpacked/foo"/> <link rel="deposit" type="application/atom+xml;type=entry" href="http://example.org/deposit/foo.atom"/> ... <app:collection href="http://example.org/unpacked/foo";> <title type="text">package contents for al's first deposit</title> <app:accept>*/*</app:accept> </app:collection> ... <entry> ... <link rel="edit" type="application/atom+xml;type=entry" href="http://example.org/unpacked/foo/resource1.atom"/> <link rel="edit-media" type="text/plain" href="http://example.org/unpacked/foo/resource1.media"/> ... </entry> <entry> ... <link rel="edit" type="application/atom+xml;type=entry" href="http://example.org/unpacked/foo/resource2.atom"/> <link rel="edit-media" type="image/jpeg" href="http://example.org/unpacked/foo/resource2.media"/> ... </entry> ... </feed> If the server supported adding further media resource to the package, you could advertise this by including an app:collection element within the feed document, as per [2]. I.e., clients would do a POST to the package-contents collection URI, as per standard Atom protocol for creating media resources in a collection. If you wanted to delete any media resources within the package, then each media resource would have it's own URI which you could send a DELETE to. If you wanted to delete the whole package, you could still do a delete on the deposit's edit-media URI as specified in the current SWORD protocol spec. I just wonder if this pattern would give you more flexibility over managing the contents of a deposited package, whilst at the same time requiring less specification of non-standard Atom protocol behaviour. I.e., this pattern needs no new protocol behaviour to be specified, all it needs is that you define the "package-contents" link relation (or whatever you want to call it) as pointing to an Atom collection containing the unpacked deposit contents. It also might be easier to implement, because rather than servers having to extend their Atom protocol engine with new operations, now everything is standard Atom protocol, and all servers need to do is implement a side-effect of the initial deposit request to unpack the package and store it in a new collection. On a different point, I also notice in the current spec that you overload the 'edit' link relation to define new protocol behaviour when POSTing an Atom entry document to the edit URI. I'm guessing that what you want here is partial update? I'm just wondering how easy this would be to implement, I'm just thinking that it may not be obvious how any child elements should be handled, whether they should add or replace existing elements. Telling the difference may require the server to have knowledge of element cardinalities, which would be hard to guarantee in general where clients may use extension elements. I was just thinking if what you want to do is selectively update portions of the deposit's metadata record, then you might be better of using PATCH instead of POST, and then having a discussion around the media-type recommended for PATCH requests, and how they should be processed. Some of the issues with dealing with this type of request are discussed at [3]. Anyway, hope this helps, and please feel free to criticise these ideas. I'm in the process of reviewing the design for a new data repository, and would like to be close to SWORD if possible. Cheers, Alistair [1] https://sword-app.svn.sourceforge.net/svnroot/sword-app/spec/trunk/SWORDProfile.txt [2] http://tools.ietf.org/html/draft-divilly-atompub-discovery-00 [3] http://code.google.com/apis/gdata/docs/2.0/reference.html#PartialUpdate On Mon, Feb 14, 2011 at 07:10:12PM +0000, Richard Jones wrote: > Hi Dave, > > This looks interesting, definitely chat about it this week. In the mean > time, you could try pointing your client at the Simple SWORD Server: > > https://sword-app.svn.sourceforge.net/svnroot/sword-app/sss/trunk/ > > I'm very close now to a draft of the spec to be implemented against. I > don't think anything there precludes the API being used as described in > your previous email. I think the SWORD and GData approaches are > compatible, but would be good to test properly. > > See you at dev8d! > > Cheers, > > Richard > > > On 14/02/11 16:38, David Tarrant wrote: > > All, > > > > Further to my actual playing with some early implementations, myself and > > Tim Brody have today extended early ideas to be closer to the Google Docs > > extensions and thus produced a client as a test of the implementation. > > > > The whole thing is best demonstrated by the video which is here: > > > > http://www.eprints.org/software/training/3.2/videos/swordv2_eprints.ogv > > > > Things we have working: > > > > CREATE : Initial create of the object > > RETRIEVE: Obviously > > UPDATE: 2 way update between both client and repository > > DELETE: Again 2 way. > > > > Additionally, Metadata can be updated to the edit-uri (also demonstrated). > > > > All of this uses the Edit-URI, Atom:ID and Edit-Media URIs only + the > > contents URIs for handling multiple documents. > > > > All the update requests are backed with HEAD requests to see if content has > > changed and on which side (repo or local). > > > > Do take a look at the video and give feedback. I think this is close to a > > full SIMPLE implementation of SWORDv2, e.g. without on behalf of and other > > complex headers. > > > > The next thing to look into is how to move the object through the workflow. > > > > See people at Dev8D where I can do a live demo. > > > > Dave T > > > > > > > > ------------------------------------------------------------------------------ > > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > > Pinpoint memory and threading errors before they happen. > > Find and fix more than 250 security defects in the development cycle. > > Locate bottlenecks in serial and parallel code that limit performance. > > http://p.sf.net/sfu/intel-dev2devfeb > > > > > > > > _______________________________________________ > > Sword-app-techadvisorypanel mailing list > > Sword-app-techadvisorypanel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel > > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > Sword-app-techadvisorypanel mailing list > Sword-app-techadvisorypanel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel -- Alistair Miles Head of Epidemiological Informatics Centre for Genomics and Global Health <http://cggh.org> The Wellcome Trust Centre for Human Genetics Roosevelt Drive Oxford OX3 7BN United Kingdom Web: http://purl.org/net/aliman Email: aliman...@gmail.com Tel: +44 (0)1865 287669 ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Sword-app-techadvisorypanel mailing list Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
