New visualisations (Franck)
Old production workflow Vancouver – DEPRECATED!!!
New production workflow Toronto
Content Capture is Drupal; this is the source of truth until all content modelling is complete. UML Class Model is EA, which becomes the source of truth once the content modelling is finished and been OK'd by the first review with the modelling team. Drupal must always be kept in synch with EA - this means we need to update packages for each object in library, and any other changes.
Plan of Attack
1. Achim to take issues 5 and 6, and get XSLTs, mapping docs, and issues list(s) up on Wiki
2. Exploration of XMI and EA documentation flows in and out - can EA/XMI handle inline DocBook?
3. Table issues 1, 2, 7, 9, 10, and 11 for now.
4. Based on outcome of step 2, address the documentation-related issues (3, 4, and 8): http://www.eadocx.com/
5. XMI export from Drupal seems dodgy - investigate!
Goal for this week is to do a prototype production run on some part of the model, to test the process!
Note that we should use not Drupal IDs, but UUIDs. We can round-trip non-EA IDs using a custom attribute in the XMI, and EA will not eat them. The idea is to have Drupal generate a UUID on export, embed it into the XMI slurped up by EA. This can be safely exported from EA for a later merge with DocBook coming straight out of Drupal.
Olof is fixing this according to the solution Achim identified. Get documentation from Achim, and explore UUID approach with Olof.
Given the process decision to do all modelling in Drupal, modelers will clean up package locations and object dupliucations before export to EA for the immediate term - issue closed
Issue 3, Disscussion:
We need diagrams for documenting the model deliverables. We have several deliverables here:
(1) The model of the entire library
a. Show the packages in the library and their relations
b. Show the objects in each package
c. Show each object and its directly related objects (like clickable GSIM)
(2) For each view
a. A diagram of all the objects in the view
b. A diagram for each object (same as 1. c)
The library contains a package for each view (in UML terms, views are just packages). There are also non-view packages in the library. Different types of packages should be given different colors
We need the Drupal XMI export to be modified, to include: Diagrams (as XMI Extensions) and documentation (as XMI Extensions). Also, we should embed the Drupal IDs into the XMI as per Achim's earlier test. This documentation will - tken from the EA export - be used to populate the XSD Documentation elements (two forms: one with forma tags stripped out, one with format tags still in, for use in the XSD HTML documentation tool used for DDI Lifecycle). Set up form for high-level documentation for authoring in Drupal. See the Roadmap for Production Process document - issue closed
We think this is already on Drupal - check with Olof
Closed - to be tested as part of prototype
Drupal: Johanna Vompras, Jannik Jensen. Olof - to be followed up next week at IASSIST
Drupal updated to include formal mappings of equivalent objects to external namespaces - issue closed
DDI4 is the Model
The Model is divided into:
- The Library
- Functional Views
The Library is made of UML Packages
- The Core Package is made of Primitives and Extended Primitives
Primitives and Extended Primitives are Objects
Extended Primitives are based (specify) on Primitives
- The other Packages are made of sub-Packages or Objects
Functional Views are also UML Packages and are made of references to Objects of the Library or constraints applied to Objects of the Library. A Functional View cannot be included in another.
This is a revised list of what products will be released:
- A PDF specification of the entirety of DDI 4. (Needs high-level documentation)
- An EA file containing DDI 4 (also the XMI)
- HTML documentation for DDI 4 (Needs high-level documentation)
For each Functional View:
- PDF specification of the view (Needs high-level doc)
- XSD for the View (with field-level documentation inline)
- Clickable XSD documentation (created using the same tool as other versions of DDI-Lifecycle)
- View OWL (in TURTL?) - field level doc as comments
- View HTML documentation for OWL
- View model documentation in HTML
- The production framework itself as a toolkit for those making their own views.
Note that this is a list of technical deliverables - #1 is the most comprehensive and authoritative document from a standards perspective. From a communications perspective, the views will likely be more important, since the deliverables around the whole model are intended for those making their own views.