Richard, Did you see my last review email in which I propose a moderately radical refactoring of the specs? For the purposes of potential standardizations, there preferably should be a number of small pieces that stand up and offer value in their own right.
Al's message suggests a further separation of concerns that makes sense to me, though in that case one of the parts builds entirely on existing standards (which is good). #g -- Richard Jones wrote: > Hi Folks, > > Last week while Dave T was in town we met up and had a chat about a > particular limitation of SWORD (and Atom, as it happens) which means it > doesn't meet the DepositMO use case requirements. > > The problem can be stated as follows: > > Given that the atom:link@rel="edit-media" IRI in an atom:entry (e.g. the > Deposit Receipt) is a reference to the entire Media Resource in some > format (e.g. a package), then when a deposit of additional content by > POST to an existing container (identified by its Edit-IRI) takes place, > the Deposit Receipt CANNOT return to the client an IRI for the resource > (or derivative(s) of the resource) that was just created. This is > problematic for the collaborative deposit use cases, where different > clients will want to be able to track or at least know which files they > were responsible for depositing. > > In order to address this problem as simply as possible, we have the > following proposed additions to the SWORD spec: > > > 1/ Add a section explicitly allowing a metadata-only object to be > created by POSTing to the Col-IRI an Atom Entry which meets the > requirements already laid out in the spec. > > At the moment there are sections (6.3.1 and 6.3.2) which detail how to > deposit a single part binary content deposit, and a multipart deposit, > but none which detail the addition of an Entry Resource only deposit. > By adding this, clients which want to can create the container first - > by POSTing an atom:entry - and then go on to add content to the > container later. This works with point (2) to effectively fix the > stated problem: > > > 2/ Add a section to explicitly allow the client to GET an atom:feed and > to POST content to the EM-IRI. > > The former of these is consistent with AtomPub as it stands at the > moment, so is uncontentious. SWORD will profile AtomPub appropriately here. > > The second of these allows the client to create new resources inside the > Media Resource itself, rather than the Entry Resource (identified by the > Edit-IRI). At the moment SWORD allows POST to the SE-IRI (which is > effectively the Edit-IRI) to add content to the container, but not to > the EM-IRI. Neither is this in the original AtomPub spec. > > The purpose of doing this is that when the server responds, it can > return an atom:entry for the deposited resource (or an atom:feed, see > questions below), giving the client the identifier that it requires as > per the stated problem. Note that this atom:entry is NOT the Deposit > Receipt as described by SWORD (at least, we don't think so - see > questions below). > > > 3/ To add to the Deposit Receipt an atom:link@rel="edit-media" with > href="application/atom+xml;type=feed" in order to support the GET of the > EM-IRI as described in (2) above. > > This will not be a requirement of SWORD, we will just duplicate the > language from the AtomPub spec with regard to how required it is! > > > There are a couple of questions and possible answers regarding this > approach: > > a/ If the response to a POST to an EM-IRI is NOT a Deposit Receipt in > the full SWORD sense, is this a failure of consistency in the profile? > Should all atom:entry responses from SWORD servers meet the criteria of > the Deposit Receipt (or rather, be formally allowed to present the same > additional elements). > > There is an extra complication here, which is that if the POST to the > EM-IRI is a package which the server duly unpacks, what does it identify > in the atom:entry as the resource which it takes deposit of. There are > a few options > > i. it could just list the package itself, if the server has retained a > copy after unpacking > ii. it could list nothing if the package was removed after unpacking > iii. it could return an atom:feed instead of an atom:entry, listing each > created resource as an atom:entry in that feed > > Dave feels that the response should be either/or depending on what the > server did with the content. > > I am more inclined to be prescriptive of an atom:entry which follows (i) > or (ii) above for the purposes of simplicity. I also think that if you > are POSTing content to the EM-IRI you should, in general, not be using > packages. Adding packages can still be done via POST to the SE-IRI also. > > I also wonder whether it would be better to have all of the components > of a deposit listed as atom:link elements with a sword specific @rel > value to say that they were created during the deposit process. In that > way, the response to the POST to EM-IRI could be a Deposit Receipt in > the existing sense, ensuring consistency across the profile and making > the client/server implementations easier. > > Thoughts? > > > b/ Is the profile becoming too large? Is it worth dividing it into two > parts, one for the operations which concern only the container > (identified by Edit-IRI) and package-based operations and another for > operations concerning the individual content items and the EM-IRI? > > > c/ In light of the above, do we still need POST to the SE-IRI for adding > further content to the container? > > I'm inclined to say yes, as this means that you can add (rather than > replace) packages and metadata to the object. You can't, for example, > modify the metadata with operations on EM-IRI as it represents the Media > Resource not the Entry Resource. > > Without this option we limit the client to usage of PUT on the Edit-IRI > only, which eliminates the option to add (not overwrite) metadata. > > > > There are also some other changes suggested, to do with how responses to > Deletes are handled, and whether Location or Content-Location headers > are provided. I will attempt to clarify those in the spec rather than > enumerate the details here, for comment when the Alpha 3 version is > available. > > Sorry about the huge email - I wanted to be as clear as possible. I > will be implementing these changes and working out the guts of the > detail as I go along, so there will be an Alpha 3 spec soon for you to > look at. > > Cheers, > > Richard > > > > > ------------------------------------------------------------------------------ > Forrester Wave Report - Recovery time is now measured in hours and minutes > not days. Key insights are discussed in the 2010 Forrester Wave Report as > part of an in-depth evaluation of disaster recovery service providers. > Forrester found the best-in-class provider in terms of services and vision. > Read this report now! http://p.sf.net/sfu/ibm-webcastpromo > _______________________________________________ > Sword-app-techadvisorypanel mailing list > Sword-app-techadvisorypanel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel > ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ Sword-app-techadvisorypanel mailing list Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
