[oslc-core] Better name for OSLC indexing profile

[Benjamin Williams]

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: bwilliams at uk.ibm.com
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 <johnarwe at us.ibm.com>
To:     oslc-core at open-services.net
Date:   04-04-2011 13:22
Subject:        Re: [oslc-core] Better name for OSLC indexing profile
Sent by:        oslc-core-bounces at open-services.net



> 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
Oslc-Core at open-services.net
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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110404/fc8c95c8/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 488 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110404/fc8c95c8/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110404/fc8c95c8/attachment.gif>