Modeling and Binding Issues (minutes and discussions)

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 UML model
• the rules of mapping UML constructs to binding constructs, available in a document and in a formal configuration file
• the logic of the transformation from the XMI representing the UML model to the syntax of a specific binding type
• the syntax of the binding type

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

1. Platform adaptation (slides, image of whiteboard)

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:

1. Will versioning be an issue? For consideration: put a fixed value attribute “version” on all elements. Note it’s already in the model in the class description.
   
   
2. Loss of extension in XML – is that okay for developers?