Migration of CA Generator to UV Requirements

Background

In 2010, HL7 Canada undertook a project to upgrade the V3 Generator, with the expectation that this would subsequently be adapted for use as the Universal V3 Generator and used in HL7 V3 Publishing. Among the objectives of the project were:

• Correct "weak" points in the Generation logic that may cause generated material to vary from run to run
• Cleanly engineer and document the capabilities
• Provide for enhanced dependency support to avoid excessive re-generation of unchanged elements
• Provide for configurable source file and output file directories to adapt to a variety of requirements
• Provide for "up and down" MIF file conversions between the variety of MIF versions that are in use by various tool suites.
• Modularize the process and provide Extension capability that can be segregated from the primary processes
• Align File naming with MIF-based identifiers

The formal "hand-off" of the CA changes occurred last fall, and work was recently begun to understand the steps needed for the migration to UV use. There are a number of capabilities that are provided by the current UV generator upon which the V3 Publishing suite is dependent. It will be necessary to assure that these capabilities are in the CA Generator, and if not determine how to provide these after migration. These capabilities include:

1. Ability to accommodate EntryPoint identifiers in Visio models that specify any of three artifacts - RMIMs, HMDs and MessageTypes - even as these have been "deprecated" in MIF. (They remain fundamental to the publishing structure.)
2. Ability to create an "HMD" container for each Visio Message Type defined.
3. Recognition that the appropriate "version" for each model artifact is determined by the domain content in the "publication data base" rather than on the model artifact itself.
   • Includes the ability to force references to these artifacts to align with these versions.
4. Provide file naming patterns that upon which the UV Publishing relies.
5. Ability to constrain a "generation" to only those artifacts upon which a particular "topic" (in a domain) is dependent (including transitive dependencies)
6. Provide "reference" files from which the Publishing QA Reports are built

The CA Generator was created in a "branch" (in Gforge SVN). It is planned to undertake the migration in this same branch.

Status

GWBeeler 14:05, 15 February 2013 (UTC)

• Established a test suite based on a sub-set of an HL7 ballot run
• Created initial "Volume Definition" file for V3 Publishing
• Verified ability to use "input directories" directly from the previous (and arbitrarily located) Generator directories
• Verified acceptance and conversion of "foundation: artifacts (RIM, Vocab Data Types)
• Determined with McKenzie to undertake the updates in the context of modification to the main modules, rather than extensions.

Concerns/Issues

GWBeeler 14:20, 15 February 2013 (UTC)

Following updated after review with McKenzie

• Have yet to get complete run because of MIF validation failures, but suspect that is direct consequence of following.
• Ability for 1 and 2 above is not present.
  • Determined that existing properties were intended to cover this and will need to debug to fix
• Suspect that 3 above is in same category as previous note, but this is not yet verified

**Determined that existing funtionality intended to cover this and may need to debug to fix

• Item 4 & 5 above cannot be tested until a complete run is done.
• The references for 6 are missing from the current CA Generator, although in some cases the cross-reference schemas provide elements to record these.
  • Determined that these were not included but expectation is that the reference processing would be augmented to cover this.
• Note that the capabilities of 5 & 6 could fairly easily be maintained with the current machinery external to the primary generation as a transitional strategy.