Packaging Domains for XML-MIF Publishing

Introduction

Preliminary mappings convince us that there is plenty of "power" in MIF2 to represent a domain, but it remains for us to select the optimum packaging strategy to support both development, publication and implementation.

Background

Current Domain Structures:

• A domain contains: Preface, Introduction and Scope, one or more DMIMs, zero or more Storyboards; one or more topics, 0..* Annex (where we have put Implementation Guides.
• A topic contains: Introduction and Scope, 0..* Story Board, 0..* App Roles, 0..* TEs; 1..* RMIMs, HMDs, and MTs; 0..* Interactions, 0..* Annex (where we have put Implementation Guides.
• Ballot status and Normative Status and Release packaging occurs either at the level of whole domain, or at the level of Topic, but each artifact also carries its own status.
• Release number and artifact version number are only related by happenstance.

MIF Structures:

• publication - provides the surrounding content for the formal artifact definitions; it provides for a single instance of approvalInfo (Ballot status, etc) that applies to the whole of the publication; it holds 1..* groups and items, and a group may also hold 1..* groups and items. Items reference content through the compound id embodied in packageLocation
• package - packages anything - individual artifacts (trigger, static model, etc.) other packages, publications - each package can hold its own approvalInfo, and some the package contents can carry their own approvalInfo, others cannot. Specifically:
  • Package content with own approvalInfo: freehandDocument; datatypeModelLibrary; staticModelInterfacePackage; vocabularyModel; staticModel; serializedStaticModel; derivedStaticModel; interactionProfile; conformanceProfile; publication; package
  • Package content without approvalInfo: domainAnalysisModel; structuredDocument; domainInstanceExample; storyboard; triggerEvent; interaction; applicationRole; testScenario
    MIF NOTE: the first two of these - domainAnalysisModel and structuredDocument surprise me since they are currently being balloted and approved within HL7 as stand-alone specifications.

Primary Packaging Alternatives

Mapping the domain and MIF structures exposes two obvious alternatives, although it should be clear that a blend of these could also be followed.

package-based Packaging

In simple terms, one takes advantage of the hierarchy available through the MIF package to create a parallel to the current "domain XML" files. Hierarchically, one will see:

• package at domain-level (scope and introduction are in package/annotations) contents include:
  • staticModel(s) for the DMIMs
  • storyboard(s) at domain-level
  • package(s) for "topics" (with header/approvalInfo for the topic
    • storyboard(s)
    • applicationRole(s)
    • triggerEvent(s)
    • staticModel(s) for RMIMs, HMDs and MT. Note: These will provide only the relationships and walk-through. They will reference the full static model from another file. How is this done?
    • interaction(s)
    • publication(s) for annexes (?)
  • publication(s) for annexes (?)
• publication for the domain. The preface (Notes to balloters) resides in the annotations.
  • publishedItem for the domain package

publication-based Packaging

• • publishedGroup for the domain-level content (Introduction, DMIMs, domain story-boards)
    • publishedItem for DMIMs (reference all static models at domain level, and preceding text holds boiler-plate, if any
    • publishedItem for storyboards (reference all storyboards at domain level, and preceding text holds boiler-plate, if any
  • publishedGroup for each topic [NOTE: This and the two items above seem redundant since they replicatge structure that is already in the package. Their sole purpose is to capture "boiler plate" preceding text fopr the sub-groupings. Is it worth it??
    • publishedItem for Intro - topic package
    • publishedItem for storyboards
    • publishedItem for applicationRoles
    • publishedItem for triggerEvents
    • publishedItem for staticModels
    • publishedItem for interactions
    • publishedItem for annexes
  • publishedItem for annexes