Unable to render {include} The included page could not be found.
Unable to render {include} The included page could not be found.
Unable to render {include} The included page could not be found.
Unable to render {include} The included page could not be found.
Unable to render {include} The included page could not be found.
Unable to render {include} The included page could not be found.
Unable to render {include} The included page could not be found.
Unable to render {include} The included page could not be found.

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Section
Column

Navigation Map
home
titleProject Home
cellHeight20
cellWidth200
Navigation Map
sprints
titleEvents
wrapAfter1
cellHeight20
cellWidth200
Navigation Map
overteam
titleOverarching Teams
wrapAfter1
cellHeight20
cellWidth200

Navigation Map
contentteam
titleContent Teams
wrapAfter1
cellHeight20
cellWidth200

Column

 

New visualisations (Franck)

DDI 4 Process.odp

DDI 4 Process.pdf

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 (tick)

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!

Issues

Goal for this week is to do a prototype production run on some part of the model, to test the process!

UI Expand
titleIssue 1: How do we round trip package library locations for object from EA back into Drupal

 

Issue 1:

 

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.

UI Expand
titleissue 2: what happens in model integration - assignment to packages, collapsing objects

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

UI Expand
titleissue 3: documentation - what diagrams are needed, what do they look like

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 (question)

UI Expand
titleissue 4: what is the documentation flow from drupal to EA

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

UI Expand
titleissue 5: xmi to OWL (validate it) - document as well as tool, Issue 6: xmi to xsd (validate and complete transform) - document as well as tool

XSLTs, mapping docs, and issues list(s) up on Wiki:

Issue closed

UI Expand
titleIssue 7: DocBook profiles for all documentation outputs to be identified

We think this is already on Drupal - check with Olof

UI Expand
titleIssue 8: Identify exact workflows for all documentation outputs

Closed - to be tested as part of prototype

UI Expand
titleIssue 9: Identify people and resources for each product, so we understand how much work it will be

Drupal: Johanna Vompras, Jannik Jensen. Olof - to be followed up next week at IASSIST

UI Expand
titleIssue 10: Discuss non-XSD, non-OWL products (SQL, Java, C#) and prioritize
UI Expand
titleIssue 11: Discuss how to formall record mappings to other standards (at level of model, at level of XSD, at level of OWL)

Drupal updated to include formal mappings of equivalent objects to external namespaces - issue closed


Narative

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.

Products

This is a revised list of what products will be released:

Whole Model:

  1. A PDF specification of the entirety of DDI 4. (Needs high-level documentation)
  2. An EA file containing DDI 4 (also the XMI)
  3. HTML documentation for DDI 4 (Needs high-level documentation)
    For each Functional View:
  4. PDF specification of the view (Needs high-level doc)
  5. XSD for the View (with field-level documentation inline)
  6. Clickable XSD documentation (created using the same tool as other versions of DDI-Lifecycle)
  7. View OWL (in TURTL?) - field level doc as comments
  8. View HTML documentation for OWL
  9. View model documentation in HTML
    Tools:
  10. 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.