On 18 Mar 2011, at 09:46, Tim Brody wrote: > On Thu, 17 Mar 2011 21:55:37 +0000, Scott Wilson > <scott.bradley.wil...@gmail.com> wrote: >> On 17 Mar 2011, at 21:28, Richard Jones wrote: >> >>> 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 --> > > Hi, > > My instinct is CMIS is only worth pursuing if you need to talk to an > existing system talking CMIS (e.g. Microsoft Sharepoint).
Or indeed a system that incorporates CMS functionality such as a VLE. However my argument is: if it looks like CMIS-type functionality, leave it to CMIS and out of SWORD. Implementers that are interested in that level of interop can go implement CMIS if they think its worth it. i.e. don't try to make SWORD into "simple CMIS" > I think someone > earlier pointed out our methodology is RFC-orientated i.e. minimal, > well-defined and, where relevant, re-using existing Internet RFCs. CMIS, by > comparison, defines a full query language, ACLs, CMS-orientated APIs ... Exactly, which is why this new "package content editing" aspect of the spec concerns me. I think to do this "right" you probably do need something like CMIS. I'm not convinced its actually needed in SWORD at all, and goes against the principles of simplicity that made it successful. Remember why we are even talking about packages - not because people want to edit them, but because we have interop issues due to too many conflicting sector-specific package+metadata content types. > What I've been pushing for with SWORD is: > 1) Re-use sensible paradigms from existing AtomPub profiles (CMIS/GData) > 2) Behave like an AtomPub implementation (i.e. don't MUST something that > isn't MUST in AtomPub) > 3) Modularise the spec. and features to enable flexibility +1 > > I just echo what Dave Tarrant has said about talking in real-time with > this. I can see Richard has injected ideas from various sources into the > spec. but these ideas need to be thrashed out between multiple brains. I > was initially thinking we want to add behaviourial controls through headers > whereas I'm more convinced now that these should be IRI parameters, which > will make it more obvious that this IRI is going to behave differently to > the base IRI. > > -- > All the best, > Tim. > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
