[oslc-core] Better name for OSLC indexing profile

[John Arwe]

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110404/df4d57ec/attachment-0003.html>