Hi Tim, >> 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. > [snip] > > Your comment is along the same lines as what I have suggested (but > probably not as clearly). I'm pushing this as an alternative to > packaging though. My feeling is it is simpler to spec (hence implement) > multiple URIs to represent a package than it is to agree to a metadata > format and file structure inside an archive.
In essence I think we're all arguing the same point from different starting points. The purpose of the Statement has always been to supply to the client a list of the resources on the server, so that then you have URIs on which you can do operations. But what we haven't done is made this suitably clear in the documentation/discussion/spec. I am, therefore, going to have a go at clarifying this in the next version of the draft (which will be in a week or so, once I've had time to assimilate feedback). My worry originally was that doing this explicitly would be too large a leap from SWORD 1.0 to SWORD 2.0, but it might be that we would be better off doing it now rather than waiting. > Ian Stuart's concern is the > overhead involved in the multiple HTTP requests that would be required > to build up the complex object. (Not that this precludes the > fire-and-forget ZIP of all your files approach) We definitely have to support packages and packaging. Ian's objection stands, but further to that packaging is well entrenched in our sector and we all know that it's hard to change the way that people work, and that we'll be more successful if we go to meet them rather than forcing them to come and meet us. > This doesn't escape having to agree a data model for what we're moving > around though. You have specced a top-level entry containing one file > per sub-entry. Experience would indicate you need to have another layer > of abstraction to support HTML-formatted documents (one or more HTML > files + inline content). This is actually my main concern regarding GData. Its idiom is a filesystem with folders and files, which is a widely used idiom but not something that I want to bake into SWORD. When I write something in the specification about being able to do GET, PUT, and DELETE on URIs supplied in the Statement, I'll simply indicate that the Statement can be part of any larger RDF or Atom document (such as a GData folder feed), and leave it to implementations to interpret. Hopefully we don't need to add any more semantics to handle this. Cheers, Richard ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Sword-app-techadvisorypanel mailing list Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
