Reviewing the comments to here, my sense is that it's not clear that the scope should include content management style functions. I'd say: if in doubt, don't do it. Or: keep it simple.
I think there's a danger that the effort could flounder by attempting to do too much in a single cycle. (I haven't had time to read the spec recently, so if my comments miss the mark, please just ignore for now...) Just because SWORD does not specify content management functionality doesn't mean that systems cannot implement it. Later, it may emerge that there's an appropriate way to extend SWORD to extend the range of interoperability to content management. But so far, I'm not sure there's a case that it's needed. In any case, I think that any content management functionality should be kept carefully separate from the simple deposit and retrieval API, so applications aren't forced to implement stuff they don't need. Which argues (to my mind) for doing a spec without content management before thinking about adding it in. #g -- Richard Jones wrote: > Hi Folks, > > There's been some great discussion on the list this past week or two, > and I thought it might be time for a summary of what looks to me to be a > key sticking point: the scope of sword. > > There are two distinct sides to this argument as it's been articulated > on this list: > > a) That we should adopt the approach of content management API like CMIS > or more likely GData > > b) That SWORD should be not say anything about what happens to the > content once it is sent to the server. > > In general, I am against (a) for a number of reasons. First, I am > concerned that the idioms that are associated with GData are not > /necessarily/ appropriate. The hierarchical file system is a common > idiom but an idiom nonetheless, and it wouldn't be SWORD's place to > therefore build itself over the top of it. CMIS I have a harder time > refuting or accepting, so am open to persuasion either way. Secondly, I > don't see a reason to re-create a content management standard, since > they already exist. SWORD should, instead, provide support for the > things that these standards don't provide for our sector/use cases, > while not preventing the use of them. > > From a purists perspective of (b) the main thing that SWORD offers, > then, is support for Packaging (with a capital P). This is a valuable > addition to the community since it is both common in our sector and > expressly not covered at least by GData and I believe not by CMIS > (though again, open to correction). The support for packaging, though, > needs to extend to a full CRUD implementation of AtomPub, which is a > large part of what the profile attempts to do. I think we have had some > good technical discussion which which will allow the next draft of the > profile to do better at that. > > In the mean time, there are some grey area parts of the profile, > particularly In Progress and Suppress Metadata which are more content > management than they are deposit. I, personally, think these are > important; they are light touch, the profile doesn't mandate the server > to obey them, and they help fulfill known use cases. Likewise the > Statement could be viewed as more content management than not, although > we have tried to pitch that as more an informational resource rather > than an operational one (i.e. read but not write). > > What I'm going to suggest for the next draft is as follows: we'll put > some more time into analysing the appropriate ways of updating and > overwriting deposit packages using the feedback on this list. And we > will extend the profile to cover how you would use the SWORD headers to > be used in content management operations /if that's what your > implementation wants/ (e.g. how you might use Suppress Metadata or In > Progress with GData). There will, obviously, be plenty of time for comment. > > In conclusion: we must constrain the scope of sword to something which > doesn't tread on anyone's toes and is of value to the community. Too > far one way or the other and we'll either be superceded or of no value. > > 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 > ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Sword-app-techadvisorypanel mailing list Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
