Agenda

1. Quickly review minutes from last meeting.
2. Jim C. to discuss changes to draft specification.
   1. Do we need to explicitly support json? The RM and QM teams are considering not including it in specs.
   2. Do we allow specification of specific properties when requesting an OSLC resource, is it also applicable with raw contents of generic resource.
   3. Scope of query language, which scenarios require it.
3. Jim A. to present document of some issues, which we will pick on to drive deep on.
4. Jim C. to present some new scenarios to coinsider.

Minutes

Atendees: Brenda Ellis, Ian Hancock, Marnie Andrews, Scott Cowan, Steve Abrams, Vishwanath Ramaswamy

1. Jim gave a brief overview of the minutes from the last meeting.
2. Steve first appologized for missing last to OSLC AM meetings, and asked us to step back a bit and think about what problem is that are we trying to solve.
3. Jim gave his summary that we defining how a tool agnostic respository should manage design resources, and integrate them with other resources. We want to facilitate resource use that 1) is available as reference and navigated through the normal course of software development, and 2) later supports automated or semi automated impact analysis.
4. Ian said that in the System Architect integration with Synergy Change, the user logs in and sees work items, sees what changes were a result of something. The user wants to know why something changed.
5. Brenda added that this is critical. We need links from the elements to the requirements, and we need to see this bundled, if we are to ever understand why things have changed.
6. Ian said that if there are a lot of changes, want to see them as one group.
7. Brenda described 2 related, one where we can see the changes delivered as part of change set. In this situation the changes have been made and can be found by examining the change set and work item records. In the other case we want to see something similar, but before the changes are actually made. We need to see a bundling of potential changes (to be models) associated with the work items and including requirement references.
8. Jim said that he's familiar with the concept of review and approve. This is where someone explicitly collects and bundles a disparate set of resources to be reviewed and commented on as a bundle. For example produce and impact analysis accessment, or cost assessment.
9. Steve mentioned that change sets associated to work items can provide some of this today.
10. Brenda also described a scenario where model elements migrate from one tool to another. For example starting off as a System Architect element, but when implemented as a service that same concept moves to RSx for further development. Or an embedded solution moves to Rhapsody.
11. Ian said that currently this problem has been solved with proxy items.
12. Jim said that in the ideal world there is just the one concept, even though multiple tools might have a representation of it. He used the mantra 'A use case is a use case is a use case' to explain the desired perception of use cases as worked in a requirements tool like RRC, and a use case in RSx, or in System Architect, or Rhapsody.
13. Steve suggested in this world we have one common uri for the concept, but with others representing thier other views.
14. Brenda offered the analogy of a single cube with different faces.
15. Ian warned of the complexity in common things like a person changing some common data.
16. Jim posed the thought that perhaps we could define a special 'equivalent link' that connected two real resource implementations, with a common URI, that indicates that these resources are in fact conceptually the same thing.
17. Ian mentioned that drag and drop scenarios can use this canonical link, and resolve to the implementation specific ones when necessary.
18. We all agreed that architecture management certainly has some significant inherent problems that other oslc teams dont (except maybe the scm team).
19. Jim proposed that the OSLC AM could define a small set of terms that could be used as properties on links, instead of trying to define link types. These terms could be well understood concepts like 'is impactable'.
20. Steve offered steve: in CM has state model, but spec just simplifies it to open/closed.
21. Ian said that in System Archiect they do have a smaller set of terms that are well understood.
22. Ian came out with a great comment: "we need to think of how do we want to use the tool, instead of how the tool wants to be used", and mentioned that some of us tool vendors think about things different than the tool users.
23. Time ran out, and Brenda had to leave with us with a reminder to not forget product lines.
24. Jim asked if she could prepare 5 min intro to product lines for the next meeting.
25. Jim also accepted the action item to start a page on the wiki where we could list potential terms for link properties.

-- JimConallen - 03 Sep 2009