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 <[email protected]> To: [email protected] Date: 31/01/2012 07:07 PM Subject: Re: [oslc] Reconsidering the "S" in OSLC Sent by: [email protected] 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 [email protected] http://open-services.net/mailman/listinfo/community_open-services.net
