John Agreed on all counts; I was not suggesting that designing both capabilities (changelog, enumeration of all resources) to be orthoganal was not desirable. The first part of my initial email was the thought process leading to my question 'why the need for something - in the context of ChangeLog - called 'Resource Publishing Capability?' (and therefore why the need to debate its name?)
Regards Benjamin Williams Rational Reporting Strategy Lead Senior Product Manager, Rational Reporting IBM Software, Rational Phone: 44-118 9793107 E-mail: [email protected] Find me on: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU From: John Arwe <[email protected]> To: [email protected] Date: 04-04-2011 13:22 Subject: Re: [oslc-core] Better name for OSLC indexing profile Sent by: [email protected] > I want to understand the relationship between 'publishing resources' to be > made available via the change log, and 'publishing resources' as a general > OSLC API construct. > Are these two things always describing the same capability, and therefore > the same set of resources? "always...same" and "the [change log]" trip my coupling warning sensor. A change log/history for a given set of resources seems like a useful primitive. A well-known way to enumerate all instances exposed by an implementation, +1. Combining those two, +1. Making their conjunction the -only- way the first can be used, -1. > I believe so. Whilst I don't believe that all indexers will always want to > index all available resources (often indexing a subset of resources might > be desired), I do believe that we shouldn't second-guess the use-cases, So if particular subsets of resources can be interesting for certain use cases, even if we're not focusing on those right now, why would we not keep the two concepts (change log, enumeration of the 'all resources' set) orthogonal so that (should one or more future use cases require it) specs/implementations need only specify how to find the change log -for a specific (sub)set- ? The case now under discussion (change log for all resources) is then simply one case of specifying how to make that association, we do it for that specific case now, and the door is left open for any of the domains or future-Core to add other "change log for resource subset X" associations as their use cases require. > and thus the set of published resources for the change log should indeed > be the exact same set of resources 'published' via the generic OSLC API. > (Note this doesn't imply that providers should not also be able to make > subsets of resources available via additional Query Capabilities) > > In other words 'published resources' is a term with a single well defined > meaning (the total set of resources available via the providers OSLC > service) that has applicability beyond just the ChangeLog proposal. Fine to me for the use case under discussion. I simply want to do so in a way that preserves flexibility to re-use the same concepts in new ways in the future. Best Regards, John Voice US 845-435-9470 BluePages Tivoli Component Technologies _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
