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

Decision for package-based Packaging

I initially attempted to structure a pair of documents to implement publication-based Packaging, and began to run into snags. In order to articulate those problems, I created this document, and then realized that the snags would be almost insurmountable.

The problem, simply stated, is that a "flat" domain package as used in publication-based Packaging does not permit adequate control over approvalInfo. This style provides for approvalInfo in only two places - the package and the publication. This does not permit he assignment of different approvalInfo for storyboards, interactions, etc. when those elements are in topics whose approval level differs. The only way to circumvent this is to create sub-packages within the main package for each level of approval, but this is coming very close being the same as package-based Packaging.

There were additional considerations, as well. With publication-based Packaging:

• there is a requirement to keep two complex documents (package and publication) in synchrony ratgher than only one
• distribution to implementers will require both 'package' and 'publication' whereas the latter is not required with package-based Packaging.