Warning | ||
---|---|---|
| ||
Link to Production Process and Tools Support page |
Current Minutes:
Minutes from the Minneapolis Sprint on production model Sprints on modeling and binding:
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:
|
Expand | ||
---|---|---|
| ||
Complex Data Types (used to be Extended Primitives): 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? |
Original Tools Support Team minutes for 2014
Expand | ||
---|---|---|
| ||
Attendees: Johanna, Johan, Olof, Jannik Drupal
Todo
Other issues on GitHub: https://github.com/ddialliance/lion Transformations A waiting review from Oliver |
Expand | ||
---|---|---|
| ||
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. |
Expand | ||
---|---|---|
| ||
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. |
Expand | ||
---|---|---|
| ||
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.
|
Expand | ||
---|---|---|
| ||
Tools Support Meeting June3, 2014 Jannick Jensen Johan Finn Johanna Vompras Olof Olsson Arofan Gregory Marcel Hebing Not present: Achim Wackerow, Dan Smith, Jeremy Ivreson, Ingo Barko Note: we haven't asked Oliver Hopt if he is interested in being part of this yet, but we should Agenda: - The timeline for developing the production framework - The developments to date, and known issues - The run through we did as part of last weeks’ sprint - The Git instance we have for tracking issues - Work assignments and availability First production run must be done by mid-September. There were some concerns, especially since the Europeans tend to take lots of summer vacation: Jannick & Johan out all of July; Olof and Johanna out half of August; Marcel we don't know. We will try to compare resource requirements estimates with people’s availability as soon as possible, to get a sense of what may be needed. In order to make resource estimates, however, we need a unified list of tasks/issues. All issues/tasks will go into the Github instance – Wendy’s e-mail list of Drupal issues must be moved to Github. Marcel will send the list of issues which was on the Wiki to Olof so we can make sure they are all listed there. Olof will tell Jannick where to put the latest versions of the XSLT transforms (XMI-XSD, XMI-OWL, from Assembla) so that these are under source control. This should also include the mapping documents. Periodically (every two weeks) we will try to do a production run, and record the results (like at the IASSIST sprint). People agreed in principle to bi-weekly meetings. Skills and Assignments: Jannick – XSLT transforms for XSD and RDF Johan - Drupal/XSLT (Could include DocBook transforms) Olof - main Drupal guy Johanna - Drupal Oliver Hopt? - XSLT (Arofan to ask). Marcel - general analysis, and to worry about long-term alignment with collaboration platform. Also, to chase down production of non-XSD, non-RDF products. Achim – General analysis of XMI, DocBook, etc. Ingo may have someone who can work on Enterprise Architect APIs – need to follow up once we know what is needed here – batch diagram export? Arofan - facilitator Everyone was made aware of the Wiki page for the production run at the IASSIST sprint. Olof spent some time showing Johanna what we already have in Drupal. Other Actions: Everyone needs to ask their management how much time they can spare - to tell Arofan in the next week or so after IASSIST. Olof/Johan to open Github to allow anyone to file issues. People should register with Github and send username to Olof. E-mail to schedule next meeting will be circulated (Arofan? Therese? How do we handle this?) E-mail to see if a face-to-face meeting is possible, or possibly a virtual sprint? (Again, how to handle?) |