Agenda

1. Quickly review minutes from last meeting.
2. Review timeline and service specifications.
   1. Introduce draft specifications currently evolving in wiki.
3. Jim A. to present document of conclusions from previous meetings discussions.
4. Derry to present development scenario for discussion.

Minutes

Atendees: Anan Yeung, Chris Armstrong, Derry Davis, Jim Amsden, Jonathan Harclerode, Maneesh Goyal, Marnie Andrews, Scott Bosworth, Scott Cowan, Srinivasan Renganathan (Ren), Jim Conallen

1. Briefly reviewed minutes from last meeting
2. Introduced Chris Armstrong as new participant
3. Jim C. gave a briefoverview of the goals of this team, and pointed to the newly created draft proposal section. He said that our approach should be similar to the CM team's in that we only need to define the common information across all modeling, and not to get mired in defining new model/artifact formats.
4. Scott B. corrected this by saying that what the CM team actually did was realize that to support the scenarios they defined, they did not need a lot of this extra information, and only what was required by their scenarios was what was put in the specification.
5. Derry D. presented a usage scenario for AM that he has worked on. He described a process where several different types of models were created in very different forms to capture the data model and UI models. The data models were captured with XML schemas, and then used by EMF tooling to generate code (as well as other model representations i.e. ecore).
6. UI models were captured in Excel spreadsheets. UIs were generated from these spreadsheets.
7. Jim C. asked if there were any explicit relationships/links defined between the data models and UI.
8. Derry responded that no, they did not manage any explicit mappings or links. He also said that they used a MVC pattern, and that the controler code was hand coded. References to elements in the data models or UI were manually handled, and if broken they would be exposed in the build results.
9. He went on to say that at first they spend a lot of time getting the models right, but after some experience the overall process flowed well. They used a template driven approach to code/application generation.
10. Jim C. asked if the client/customer [stakeholders] viewed the models directly to provide feedback.
11. Derry said, maybe some technical users might do so, but in general they would generate the UI and work with the client to get feedback on missing/invalid information.
12. Jim A. commented that this is similar to many processes, and similar to how Ruby on Rails does things where models are commands. he questioned that with so many artifacts and types sitched together did they rely on any specific standards for the data model or ui views? How are these models related together.
13. Jim A. went on to comment that in the current draft proposal we have model elements (ME) and resource links, and posulated that maybe the links could also be behaviours (i.e. transforms). That the connection between some of the atrtifacts be the transform itselfs.
14. Jim C. quickly added, or the invocation of the transforms could also be responsible for creating the 'links'.
15. Jim C. asked if they did formal impact analysis in this scenario, and Derry responded no, not at that time. However as he brings this into the future that is a desire.
16. Derry added that what he really wants to see is a model management system that is tool agnostic, enabling Tool A to produce artifacts that can link to artifacts create by Tool B, without Tool A being aware of Tool B.
17. Jonathan H. added that in the environment that he works in this proxy element (i.e. OSLC Model Element) the names remain the same. They don't explicitly manage a unique identity (GUID).
18. Jim A. pointed out that names for these things are inherently unstable and often change, and without full control over refactoring can easily get out of sync.
19. Jim C. pointed out that while this might not work for every customer, it seems to be working for them. That in these two development processes, the changes to element names is infrequent enough, or does not cause severe enough impact to warrant the extra overhead of managing UUIDs.
20. Jonathan H. said that things to change, however they've managed to deal with them during regression tests or builds, after the fact.
21. Jim C. pointed out that time was up, and asked Jim A. to document his comments and thoughts regarding a number of issues, and he will be the first to present next time; first with an overview of the six (6) items he currently had, then we as a group would pick one to drill down on.
22. Jim C. also asked everyone to review the developing glossary/terms that Vishy created on the wiki, and to look over the developing draft for the 1.0 specifications for the REST api and resource formats.
23. Derry added, that he would like to continue with the discussion prompted by Jim A's comments that a transformation (behavior) could be the link itself between resources.

-- JimConallen