Hi Scott, >>>>>> 6.6. Adding Content to a Resource >>>> >>>> I'll get onto this and point, just as a pointer however look at the >>>> 'Creating a folder' section in the GDocs API. >>> >>> This whole area of SWORD (secs 6.4-6.6) is effectively doing the same job >>> as CMIS. Is there a good reason for creating a new spec here? >>> >>> If these kinds of operations (remotely manipulating the content of virtual >>> packages) are part of the core functions of SWORD, should it be a profile >>> of CMIS rather than AtomPub? >> >> I've tried /quite/ hard to get to grips with CMIS without a huge amount of >> success. It seems extremely large and full of a lot of stuff which is way >> way way over the top for what SWORD is trying to achieve, as far as I can >> tell. > > It is indeed rather more complex than SWORD as it is handling content > management rather than just deposit --> > >> >> Also, we tried in the business case/technical architecture document to >> position SWORD firmly in the "deposit" space rather than the "content >> management space" (which I may or may not have succeeded in doing). >> Certainly I can see the case that enabling CRUD means that you are doing >> some content management, so we're striving to keep the details of what we >> say based entirely on the aspects of transferring data point to point rather >> than mandating what happens to that data at either end (this is, for >> example, part of the reticence to formally incorporate GData). > > > --> and so we really have to make sure the scope is correct. It has veered > into CM with all these operations on the content of packages.
So, I think it's inevitable that there will be some operations which could be considered content management by the very nature of allowing CRUD. But CMIS applies a domain model to the server end, which SWORD doesn't do - I think this is a key distinction. I'd be interested in your comments on the other email that I sent just now about the scope of sword. >> So, profiling CMIS seems like a massive undertaking and a large burden on >> the implementers just to make sense of what they would or wouldn't have to >> implement. Could you comment on that, do you think? > > Actually I don't think profiling CMIS would be at all necessary. If SWORD is > about deposit, and CMIS is about CM, then implementers can choose the specs > they want to support based on the functionality they want to expose. > > So some implementations may just want to support deposit with some packaging > format hints, while others may want to look at implementing CMIS (e.g. using > CMIS libraries such as Apache Chemistry) - either instead of or as well as > SWORD. > > At the moment there seems to be an assumption that a solution halfway between > SWORD 1.x and CMIS is desirable. I think that even half way to CMIS is a pretty long way .... :) >> What does seem possible is that we could adopt terms from the CMIS namespace >> to use in SWORD, rather than minting new terms. I'm thinking, for example, >> of cmis:createdBy being used instead of sword:depositedBy, although there's >> some argument to be had over whether those two are really the same thing. >> Could you possibly suggest some similarities in terms in CMIS that might be >> appropriate for reuse in SWORD? > > See above ... > >> >> Also, do you know of any good introductions to CMIS that are bit more >> penetrable than the specification that I could look at? > > Playing with the Apache Chemistry libs is probably more rewarding than > reading the spec as you can see what its doing. > > http://chemistry.apache.org/ Thanks, that sent me off on a pretty useful direction. For anyone else interested in CMIS, I found this basic introduction pretty instructive: http://www.oldschooltechie.com/blog/2009/11/23/introduction-cmis Cheers, Richard ------------------------------------------------------------------------------ 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
