...
Expand | ||
---|---|---|
| ||
Attending: Arofan, Achim, Oliver, Flavio, Marcel, Anita There was agreement on: The production framework for the generation of bindings should be separated. It makes sense for good documentation and for maintenance of the production framework, especially adjustment for future needs. The focus is on these binding: XML Schema, RFS-S/OWL (the sequence expresses priority). This applies to these levels:
The ideal structure according to this approach is that the Platform Independent Model (PIM) in UML can be transformed according to the rules of a specific binding type to a Platform Specific Model (PSM). The rules are realized as formal configuration file. The PSM is again realized as UML model. A second transformation can transform the PSM into the specific syntax of a binding type. The chosen syntax can be realized in a configuration file. Another option is to combine both transformation steps into one. This would be an easier effort in the first place but the concerns are not clearly separated. The documentation and the maintenance could be therefore more complicated. For any solution it is important to defined specific subsets of each level representing the model. This comprehends the used UML, the XMI representation of the UML, the chosen set of the syntax of each binding type. A consistent structure is important for documents and configuration files for describing the mapping rules for the multiple binding types. The described approach needs further exploration and evaluation according the overall effort and possible advantages and disadvantages. The currently available XSLT for the XML Schema binding, the existing documents (output of previous Moving Forward meetings), and scientific articles from research are the basis for further work.
There was agreement on: We separate the transformations. → Step 1: platform adaptation → Step 2: syntax generation → We need a comparable documentation for all bindings (for developers). → How to define the configuration? → Documentation of both steps: human readable! machine actionable? → How to handle element-specific
All abstract objects are ignored for XML schema 2. Views go into a view specific namespace, with the root element (named after the view) All other objects in the view are declared directly in the schema in a “ddi” namespace on imports Questions:
|
Attachments |
---|