Hi Scott, >> 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.
Do you think you could expand on that a bit? In my mind, we're not doing any package content editing, we're just either adding new/more packages to the server (possibly to the same container) or overwriting old ones, not giving the client a way to edit the contents of the packages. The Statement, which might give this impression, is supposed to be informative rather than operational, except in cases where it is implemented as part of, say, GData. If some part of the profile is suggesting that packages can be edited by SWORD that should definitely be clarified. It certainly feels to me that the scope of SWORD is becoming clearer through this discussion - keep it up! Cheers, Richard > 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 > ------------------------------------------------------------------------------ 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
