Agenda

1. Jim will update workgroup on core activities.
2. Continue discussion from last time about whether this workgroup should begin defining specific resource types and shapes. Review list of common resource types, that we started last time.
3. Continue discussion of baselines, Tom and Dan B's scenarios.

Minutes

Atendees: Ahmed Oraby, Alanna Zito, Dan Berg, Dan Leroux, Mahmoud Oraby, Peter Yee, Bob Maksimchuk, Scott Bosworth, Tom Piccoli, Sandeep Kohli

1. Jim updated the team with the Core status. Not much that directly affects this team, http://open-services.net/bin/view/Main/OslcCoreMeetings20101013. We discussed some guidlines on how to ues namespaces and terms, and how the OSLC will host a landing for them (i.e. if a client does a GET on the term on the internet, the client will get information from the OSLC site describing it).
2. The concept of a "Change" in our terms section was discussed. Tom clarified that the term might really be a "change set". Jim took an action item to work with Tom to update this term.
3. Scott said we need to be thinking of change as a life cycle concept and can involve all sorts of stuff (i.e. different resources in different domains).
4. Tom raised the concept of a composite baseline. The team discussed the need to coordinate baselines/versions across domains and service managers.
5. A lot of discussion happened around the need to link versions of resources, and how pickers would behave in baselines, and composite baselines. It was suggested that a picker could optionally provide a version specific URI for a resource, since it being hosted on the server managing the resource is the only thing in a position to provide such a URI.
6. Sandeep suggested that it might work like the way that IBM Installation Manager.
7. Dan L. pointed out that we need to consider things other than baselines, like streams, which are also a type of context that a resource version can exist. In the case of streams, there can be multiple, conflicting versions of a resource.
8. Dan B, and Scott pointed out that people want to manage change in/from a baseline. Allowing it to evolve into different versions. There needs to be a way to manage change in the old thing.
9. Dan L. pointed out again that we need composite baseline (or context) management.
10. At the closing Scott B. offered the team some advise, summarized: "this is a big problem that will eventually be addressed holostically by the core and other domains, we should not try to solve the big problem, but rather focus on the specifics that this domain might have as unique to help the larger effort later."