Link to Tool Support Team

Link to Tools Support Team Minute

PIM PSM Collections Example-2015-05-26

Mpls Sprint 2015-05-25

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

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:

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.
Loss of extension in XML – is that okay for developers?

	File	Modified
Labels No labels Preview View	Microsoft Word Document binding-minneapolis.docx	May 28, 2015 by Marcel Hebing
Labels No labels Preview View	PDF File binding-minneapolis.pdf	May 28, 2015 by Marcel Hebing
Labels No labels Preview View	PDF File build-minneapolis.pdf	May 28, 2015 by Marcel Hebing
Labels No labels Preview View	Microsoft Word Document build-minneapolis.docx	May 28, 2015 by Marcel Hebing
Labels No labels Preview View	PDF File xsd-binding-minneapolis.pdf	Jun 02, 2015 by Marcel Hebing
Labels No labels Preview View	Microsoft Word Document xsd-binding-minneapolis.docx	Jun 02, 2015 by Marcel Hebing
Labels No labels Preview View	JPEG File 20150525_123936.jpg Out of date	Jun 08, 2015 by Wendy Thomas
Labels No labels Preview View	Microsoft Word Document PIM_PSM.docx Out of date	Jun 08, 2015 by Wendy Thomas
Labels No labels Preview View	PDF File PIM PSM Syntax.pdf Out of date	Jun 08, 2015 by Wendy Thomas

Download All

Browser not supported