On 17 Mar 2011, at 21:28, Richard Jones wrote: > Hi Scott, > > On 17/03/11 08:43, Scott Wilson wrote: >> >> On 17 Mar 2011, at 00:25, David Tarrant wrote: >>>> >>>>> 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, 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. > > 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/ > > 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
