Agenda

1. Quickly review minutes from last meeting.
2. Propose change in dates for Nov-26, and Dec-24 meetings (near US holidays)
3. Jim C. to discuss changes to draft specification.
4. Gain consensus on scope of scenarios to support for 1.0 release.

Minutes

Atendees: Alan Yeung, Andy Berner, Dan Leroux, Derry Davis, Jim Amsden, Scott Bosworth, Scott Cowan, Steve Abrams, Jim Conallen

1. Jim C. mentioned the name changes in the draft specifications, and pointed out that this early draft was just created to start talking around. It was written in the same spirit as the other OSLC specifications.
2. Jim C. began a review of some micro-scenarios.
3. Jim A. raised the issue of granulatiry of resources. Jim C. responded that it was probably not within the scope of the OSLC to prescribe or even suggest resource granularity.
4. Jim C. started to describe a micro-scenario involving asset management. Some felt that this scenario belongs in asset management space.
5. Dan L. asked if the Asset Management OSLC spec already supported this. Jim C. countered that this was not the purpose of this scenario, but rather to suggest that AM resources might have links with other OSLC resources, and that the nature of the link (i.e. semantics) were important.
6. Dan L. questioned how an untype link between an asset and an AM resource would be understood.
7. Steve A. brought the discussion back into focus by asking what does this look like on the AM side. What does the AM server have to do to support this? What value does the AM server provide?
8. Jim A. added that there are two sides to this view [scribes notes were garbled, Jim A. can you fill this in?]
9. Jim A. went on to pose the idea that "isn't RAM just a large scoped referencing system?"
10. Steve A. said that the OSLC specification is not a back end interface, and it is not about how to talk to OSLC RM, CM or QM systems. What we are the use cases where a client talkeso the system.
11. Dan L. responded that we can use this to describe how to talk to other OSLC systems, if they talk to us in this way.
12. Jim A. said that most of this should be covered by an OSLC wide specification for CALM linking.
13. Scott B. asked what are the AM resources. What needs and uses do they have.
14. Jim A. said models of all sorts of things and all types of semantics, some defined like TOGAF along with other methods.
15. Dan L. asked us to take a step back and look at the other OSLC specifications (CM, RM, QM, ...) and ask them individually what they want to see in an AM specification.
16. Steve A. stated that the CM team started with just 3 domains (CM, RM, QM).
17. Jim A. posed the question, "Do we hope they will all be the same?"
18. Jim C. said there are many things that we won't be able to get to in a 1.0 spec, like baselines, versioning and product lines. He asked everyone if there was any objection to omitting these issues from the supported use cases. Everyone agreed.
19. Steve A. brought the conversation back to focus on; "what's unique in our domain [AM]?"
20. Jim C. offered that in the AM space there are lots of different modeling notations, formats, levels of abstraction, tools, to create artifacts that are used in lots of different ways (as implementations, specifications, documentation, executable, transformable, simulation, ....) unlike a Test Plan which for the most part can only be used to plan tests.
21. Scott B. disagreed and said that there are 20 different types of change requests. He asked is it possible to pick a few to cover the 80% rule?
22. Jim A. stated that what we need is a generic solution that doesn't overly constrain the servers.
23. Steve/Scott said they didn't "buy that"
24. Steve A. asked about the AM to AM scenarios.
25. The conversation was heated and productive, and it was decided that we'd schedule a follow up next week at this same time.

-- JimConallen - 30 Sep 2009