Agenda

1. Quickly summarize points from last meeting.
2. Get a consensus on:
   1. what makes AM different
   2. the essential scenarios
   3. link typing
   4. supporting custom meta information on resources

Minutes

Atendees: Dan Leroux, Derry Davis, Ian Hancock, Jim Amsden, Jonathan Harclerode, Scott Bosworth, Steve Abrams, Tom Piccoli, Vishy Ramaswamy, Jim Conallen

1. Jim C. summarized the purpose for this call as an extension of last week regularly scehduled call. He said we need to get a consensus on the essential scenarios, and hence the scope for the OSLC 1.0 spec.
2. Jim C. began our call with the last comments from the meeting last week, and asked in general do we need to discuss what makes AM different? Or can we focus on the scenarios and scope for a 1.0 spec?
3. Steve A. said that in all other domains the clients remain mostly ignorant of the formats of resources. Only the server knows the details. In the AM case clients are the only ones that know how to work directly with the formats/content of the discrete resources. This is useful for cross domain integrations. It lets other systems treat the resources as black boxes.
4. Steve A. went on to request more details around the scenarios, especially when working with links.
5. Jim C. said that in his view all the scenarios tend to focus on 1) the ability for a client to find and navigate links owned by AM resources, and for 2) automated routines to walk the resources for things like reporting or impact analysis.
6. Steve A. asked if we were doing this for all types of resources that might be in the AM system?
7. Jim C. said yes, and cited one of the senarios presented by Derry that included the use of Excel and schema files as first class AM resources.
8. Steve A. pointed out that in this generic sense we are not talking about architecture specific things, this is all general.
9. Jim C. pointed out that in previous discussions and in earlier drafts we did have interesting architecture specific concepts like a context, or container hierarchy. We also discussed baselines and product lines, which were considered critical to the overal usefulness of a AM respository.
10. Steve A. sees three categories of things 1) what does a tool need to know to communicate to a server, 2) set of things non-architecture tools need to know and 3) generic stuff like link management.
11. Scott B said we need to focus on the architecture specific (Steve's second area).
12. Jim C. said he was worried that if we didn't address the core stuff (linking, common information) first, that we wouldn't be able to even address the most common scenarios. If we didn't include how to link for example any client would have to negotiate to each implementing server anyway to get it done. This is not different than the point to point integrations that are causing our problems today.
13. Jim A. agreed, and said that we have good information in these silo-ed tools that we could use. There are known scenarios (i.e. togaf) that we can point to, that support this need for the basics.
14. Steve A. related a story from the CM workgroup. There they started off with most services being generic. Then then provided a vocabulary (i.e. bugs), so that they could do intelligent things about bugs.
15. Jim C. re-iterated, that without the fundamentals (i.e. common meta info, linking) we can't even begin to do interesting domain specific things. and that until this common stuff is consolidated across the OSLC as a whole we need to provide it in a 1.0 draft otherwise we can't do the basics.
16. Jim A. agreed but warned about doing it in a schema specific way. He also asked about the level of granularity in resources published by the server, was it scalable as we define resources as granular as a pin on a UML action.
17. Vishy said that we what we want is a representation on a AM resource that just has the basics; name, type and links. this is already being done by the other groups. the second part is when we want the resources to solve the complex architecure problems.
18. Jonathan asked if we were talking about two different types of resources; there are management resources (baselines, product lines) or architecture specific resources (Jar files, java files, UML models, spreadsheets).
19. Jim C. said this was an interesting observation and it is entirely possible for a server to provide unique pickers to these two different types of things.
20. Steve A. commented that he's seen similar conversations in different domains that are like this archi magement resource as compared to architecture resource. and when he particpates in these conversations he goes insane. The only one group where this really did pop up as a serious concern was in asset management, where the resource is always a blob.
21. Jonathan argued that in our case there really is a difference that needs to be considered.
22. Jim C. (mentioning the time left) tried to g
23. et the conversation back to the topic: what needs to be included for a 1.0 spec.
24. Steve A. asked again what are the scenarios.
25. Dan L. stated that we already have them, and cited the ones we've already listed. He also referenced the existing integrations with ReqPro? /RSA as examples of what is being done today, that needs to be supported by the spec.
26. The team collectively examined the simple scenarios page on the wiki.
27. Steve A. said that he can understand the first scenario.
28. Dan L. said that this is a simple as it needs to be. Jim A. agreed saying that for all practical purposes links are no different from each other.
29. Dan L. mentioned that today model elements are used as requirements, they implement them etc.
30. Jim A. asked if the granularity of the resources in AM might not make scalability problems later on (as we make a pin on an action a resource).
31. Vishy said that it should work, and the tools will choose what to expose.
32. Scott B. cautioned us, saying we were getting too detailed, while Jim A. suggested that a deep dive in the weeds and then surfacing might help.
33. As the meeting time closed in, Jim C gained a consensus on the selection of three of the scenarios that we can state that the 1.0 spec must support.

-- JimConallen - 08 Oct 2009