Packaging Domains for XML-MIF Publishing

Introduction

Preliminary mappings convince us that there is plenty of "power" in MIF2 to represent a domain, but we must select the optimum packaging strategy to support both development, publication and implementation. This started out as an explication of the problem, but having documented the alternatives, I have reached the conclusion that package-based Packaging is the only realistic strategy. The basis for this conclusion is laid out below.

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 and uses a simple "publication" to carry the authors, etc.. 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

In simple terms, one takes advantage of the hierarchy available through the publication/publishedGroup to create a parallel to the current "domain XML" files and uses a simple "flat" package. Hierarchically, one will see:

• package for the domain (scope and introduction are in package/annotations) contents include:
  • storyboard(s)
  • applicationRole(s)
  • triggerEvent(s)
  • staticModel(s) for DMIMs, RMIMs, HMDs and MT.
  • interaction(s)
• publication for the domain. The preface (Notes to readers or voters) resides in the annotations.
  • publishedItem for the domain introduction and scope
  • publishedGroup for the DMIMs (precedingText is boiler-plate)
    • publishedItem for each DMIM
  • publishedGroup for the Domain storyboards(precedingText is boiler-plate)
    • publishedItem for each domain storyboard
  • publishedGroup for each topic
    • precedingText for Intro and Scope of topic
    • publishedGroup for storyboards
      • publishedItem for each storyboard
    • publishedGroup for applicationRoles
      • publishedItem for each applicationRole
    • publishedGroup for triggerEvents
      • publishedItem for each triggerEvent
    • publishedGroup for staticModels
      • publishedItem for each staticModel
    • publishedGroup for interactions
      • publishedItem for each interaction
    • followingText for annexes
  • publishedItem for annexes