Production Process and Tools Support Minutes

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?

To hold the actual value of an object, the primitive should not be extended. Instead, a field with the name of "content" of the primitive type should be declared.

For any given object with an xml:lang property, it should be called xml:lang, with a type of xs:language. Thjis will appear in the schema as an xml:lang attribute. Other language properties should be given a type of xs:language, and they will become elements with te xs:language content type.

We need to discuss how dates are modeled, since the existing 3.2 union class is very XML-centric.

The XHTML binding needs also to be discussed, as this is very XML-centric.

For the XML binding, all relationships become Reference elements with a defauled attribute of "isExternal"  to a value of "false" (the referenced object is part of the View. If set to "true", it is a reference to an object outside the view. The view corresponds to the XML instance. Do we want to use this mechanism?

 Attendees: Johanna, Johan, Olof, Jannik

Drupal

•  Is in good shape and development is steady and ongoing
•  Nightly builds working

Todo

•  Graphs embedded into XMI output will be fixed incremental each week
  •  Diagram of each view
•  RDF equivalent element information is a TODO task
  •  Needs example of such a construct in the XMI - JVJ looks into this
    •  Could be comment with specific type or nested elem
•  Docbook formating issues to fix -will look into this in a week or 2
  •  Linking of the graphs in the docbook output
•  Element named 'Node' to fix not rendering in GraphWiz

 Other issues on GitHub: https://github.com/ddialliance/lion

 Transformations  A waiting review from Oliver

Attendees: Oliver, Jannik, Olof

Jannik explained what he had done on the transforms at the Toronto sprint. The transform is more or less complete. The documentation for the RDF needs some fixing, it runs only for discovery. Email and stuff like that should be added to....?[therese missed what Jannik said - maybe primitives?]

The XMI to OWL is the best one.

The outstanding tasks:

1) Reuse of elements from other standards: Referring to elements in other standards needs to cleaning up in Drupal for the exports to work well. This was discussed in the modelling team. Oliver had suggested to add a column in Drupal to show the equivalences. We should model it but not export it. So we need a place to put it. Currently in Drupal you can say that an object is equivalent to X in DDI 3.2 or GSIM. Olof confirms there is an RDF field in Drupal to show external mappings. In the RDF, do you want to use the (for example) dc terms namespace, or keep it in DDI namespace. Jannik says it is best to keep both and then make a decision later.

It should be straight forward in RDF, but in the XML we need some more information. The XML transformation that is the biggest issue. Is it feasible to inline the other standards, or leave it at the modelling level and just document it? Jannik says do both.

2) Bug fixes

3) Documentation that runs on docbook

4) Transformations to other implementations??? Do we do it?

Drupal:

Olof is working on some bugs for exporting and views in Drupal. Next step is for Docbook export.

Is it possible to do a regular run through/ test run? We could start a tools support meeting by look at the results of the test run. But do we have infrastructure support? Olof says yes. The SVGs are automated, the next step is to do the XSLT automatically. It should be done in a batches. It could be running in a week or two.

The September release should be possible technically - only issue to stop it is resourcing.

Jannik is happy to press start on the GTM meetings for future meetings.

Attendees: Achim, Oliver, Thérèse

Clarification on creation of diagrams

We want a diagram of each object and its neighbours. This will be a lot of diagrams. We could make the diagrams in EA from the XMI. This might be too much work given the number of diagrams. Olof is investigating if we can make these diagrams automagically from Drupal. The Drupal graphs are not so pretty when there are lots of objects, but maybe not so bad for small diagrams. The diagrams for views/packages should be made in EA.

Production tests

In the initial meeting of this group, it was agreed that we should try to do a production test once every two weeks. This has not been happening. We need to start doing it for the September release. To do teh production tests, we would need a Drupal person (Olof or Johanna), a XSD person (Jannik or Oliver) and an OWL person (?? Maybe ask Thomas??). This needs to be sorted out at the next meeting.

Attendees: Dan, Achim, Marcel, Olof, Thérèse

In the meeting we waled through the production flow to have a complete list of work to be done.

1. Drupal: The current work for Drupal is  on github (link). Olof has been working on the changes. Johanna has confirmed that she has some resource to also work on Drupal. Olof has sent her some information. ACTION: Olof and Johanna working on Drupal issue list.
2. EA diagrams - We said that we are going to export the diagrams from EA. We want one diagram per object (like in clickable GSIM). Can we automate this work? Is it possible to do it from Drupal instead? ACTION: Figure out how to export pictures from Drupal in .doc file
3. Olof thinks it is possible to generate a graph per object in drupal. We also want to have a diagram per package and per view. Some of the package level diagrams will be quite complex. ACTION: Olof will add 2 new issues to the Drupal list - creating graph per object and creating graph per view. (DONE)
4. Generate extended XML in export. This is a black box and needs investigation ACTION: Olof and Johan will look at this in July
5. High level text in Drupal? We need high level text like the over all introduction . This could be done in Drupal using simple pages. The key thing is to keep it simple though. If there are tables etc, maybe it is not so good to do this in Drupal. We need to talk to Jon and the main documentation guy about what he thinks the requirements are. ACTION: We need to talk to Jon
6. Docbook export - There is some work to be done to change the table structure for properties and relationships. This is in the Drupal issue list (#7). We need to test the export from Drupal to DocBook - in terms of checking the structure. Then we see if it makes sense in HTML and PDF. We want these formats to be reviewed (as well as the modelling work) when we go out for review to make sure they meet mixed needs. ACTION: Test DocBook export
7. Are we getting the XMI from EA or Drupal. The diagram says EA, but we think that Drupal is the source of truth so it should be from Drupal? We should update the diagram. The XMI should be stored in GIT ACTION: Achim will look at updating the diagram Franck drew.
8. XSD - Jannik and Oliver and the people to help with this. This transform need some more work. ACTION: More work needed here
9. OWL - This transform is more mature. There is an issue list for the work - link. ACTION: Need to work through issues in issues list.