On the call:
Jishnu chairs and takes notes
Meeting started at 13:05 EDT
The meeting was driven by the Notes from Bob Daniel that he sent via email a couple of weeks back. These notes capture the points discussed and made at the call.
We need to produce some guidance on when to use Metamodel, Model and Profile specially in the context of producing RFPs and RFCs and RFP responses.
The usage of the term Metamodel and Model in the community outside OMG is different from OMG and there are multiple of those, leading to further confusion.
Other terms that need clear definition are MOF Model, UML Model. Clearly differentiate between MOF Model and UML Model and provide guidance on when to use
This whole discussion is motivated by the issue of Association Class in what was alleged to be a MOF model at the JAX AB meeting. It was necessary to remove the Assoc Class which enabled expression as a MOF model, allowing generation of XMI for MOF model. But the fact that MOF models cannot contain Association Classes was not known to too many people. This sort of information needs to be collected in a guidance cookbook.
Guidance needed on MOF/UML constructs that should/should not be used for Model or Meta Model.
Guidance needed for Tool selection for generating XMI. This could be in the form of best practices rather than a approved list cast in stone. List of approved tools and couple of paragraphs on guidance on what models to generate and common mistakes to avoid would be useful.
As a start at addressing these issues, ssk people who have successfully gone through AB review to write up a few paras on what worked, and what did not, and why, and how they were fixed.
[AI] Bob will (with the help of Larry) write up their experience as the first example. Then will instigate others to write up their experiences and collate them as they come in.
Going forward, require inclusion of information about the tool that was used and associated details, for generating the submitted machine readable artifacts like XMI, XSD etc.
[AI] Jishnu to get this incorporated in the template that is used for submission inventory.
Include in the submission template information about what tool was used to gen. Then at the AB meeting we can record what problems were found. We will ask for this information of all submitters that include any machine readable artifacts in their submission, any problems encountered and how they were fixed, and record the information for subsequent use to get guidance together.
Document what are the requirements for XSD structure, e.g. not using containment, have to have a root object etc. For metamodels the latter may be an artificial item to satisfy the need for XSD. If XSD is a requirement and needs to reference XSD from another existing spec, what is the recommended way for referencing that XSD to be referenced from the XSD for the new spec? There needs to be a way to get an external reference, e.g. to BMM artifacts from some spec that uses those artifacts to evolve, say in defining new classes that derive from one of the existing BMM classes. This needs to be done without having to include the entire BMM XSD in the XSD for the new spec.
If there is a way to generate an XSD from XMI what is the method? Is that XSD actually useful? Will depend on What are these on what these XSDs are for? To validate an XML document that contains model information in XMI compliant way? Or something else? One view presented which most seemed to agree with is that XMI is the method for tools to interchange model info. On the other hand XSD is to drive XML tools that humans interact with, as in extending or building XML files from scratch.
Perhaps we need a specification for generating XSD to serve that specific purpose. Whether this can be done from XMI or not remains TBD. Tools generate XSD for only Class diagrams AFAWCT
We need a white paper on this. Question is who will write it? Doug T will take a first stab at such a document, but will need lot of help from the rest of the group.
[AI] Doug to take a first stab at a White Paper on XML, XMI and XSD issues.
The problem of specializing a class from another package causes the whole mess from the other package to get imported and to be made part of the new model. This is not conducive to doing independent development reusing existing models. When a MOF or UML model wants to specialize classes in an existing model, it ends up having those imported classes as an integral part of the new specialized model. This causes a reuse problem. Just as XSD has schemaImport, MOF needs a Model import.
End at 14:05 EDT
Wednesday the 23rd of June at OMG Meeting. The first hour of the SMSC meeting starting at 4pm CDT will be used for regular housekeeping work. The second hour starting at 5pmCDT will be spent on this activity. Callin Info:
1. Wednesday, June 23 at 4:00 PM Central Daylight Time at https://www1.gotomeeting.com/join/163870936
2. Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone.
Germany: +49 (0) 898 7806 6466
United Kingdom: +44 (0) 1316080046
United States: 909-259-0011
Access Code: 163-870-936
Audio PIN: Shown after joining the meeting
Meeting ID: 163-870-936
Meeting chat: http://webconf.soaphub.org/conf/room/omg-smsc
Meeting Notes: Teleconference Notes