[oslc] Reconsidering the "S" in OSLC

[Uri Shani]

Hi Katrik,
I understand that EVERY standardization effort produces specifications as 
artifacts, for some subject area, problem or domain.
The term "specifications" is never part of the subject, which should only 
briefly tell what these specifications can be used for.
In the OSLC case, it is for collaboration services. I think that in 
general the term "services" is right in-spite of the possible confusion 
with SOA.
Some may say it is a healthy confusion since the real problem OSLC 
addresses is the services. In fact, SOA could also be a possible candidate 
to carry them out.
(lets not make an issue of that now though...)
So OSLC is about servers and clients exchanging model artifacts for 
certain product life-cycle management domains, and the OSLC working groups 
produce specifications towards that goal.

Regards,
- Uri



From:   Kartik Kanakasabesan <kartik at us.ibm.com>
To:     community at open-services.net
Date:   31/01/2012 07:07 PM
Subject:        Re: [oslc] Reconsidering the "S" in OSLC
Sent by:        community-bounces at open-services.net



Hi Uri, 
          My comments tagged as  >>>> 


Indeed Katrik, what we do in OSLC is write specifications for OSLC..., 
whose goal is not the specifications, but the enablement of some Open 
Lifecycle Collaboration among Something(s), and for some domain(s) of 
engineering tools. 
I guess the S stands for classifying these "things" and/or the domains. Is 

the specifications themselves one of these? 
My comment has been that when "OSLC" comes together with the word 
"Specifications" it does not sound right. 
That happens quite allot since the major product of this effort is indeed 
- 
as said above - specifications: for AM, RM, Core etc 

>>>> When tools collaborate they need to use clear vocabulary between them 
to exchange information,so that way I agree with your assertion that S is 
the "things". The "things" in this case are the specifications which 
enable collaboration in a REST environment. Let us just assume that we did 
not take the effort to specify the different resources and how they are 
exposed. If everyone were to design their own way of exposing resources, 
we would end up with same situation we are today with proprietary API's. 
Which is why the specification development at OSLC is a industry 
initiative which is producing specs. 

Regards, 
Kartik _______________________________________________
Community mailing list
Community at open-services.net
http://open-services.net/mailman/listinfo/community_open-services.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20120201/92ad018b/attachment-0003.html>