This wiki has undergone a migration to Confluence found Here
New ITS Guide
Revision as of 10:51, 9 February 2007 by Charliemccay (talk | contribs) (→Design Principles: changes from XML ITS R1)
Contents
Preface
Notes to Readers
This is a work in progress draft, and far from complete
Acknowledgements
Changes from Previous Release
Prerequisites, Assumptions and Conventions
Known Issues and Planned Changes
Overview
Introduction and Scope
This document describes the rationale for the decisions taken when developing and maintaining the ITS. This information is provided to support the use of the specification, and is not intended to restrict or extend the meaning of that specification. Where there is a difference, the specification takes priority over this document.
Design Principles
- The transform from the abstract model to the instance should be as simple as possible.
- The instances should be pleasing to the eye of a human reader.
- Names should be determined in the abstract model, not generated by the ITS
- Without compromising other principle listed here the instances should be as small as possible.
- The ITS should define the set of valid instances for a V3 artefact, and a W3C schema that describes that set. Every valid instance must be schema-valid against the defined W3C schema for that instance. It is also noted that other schemas may be used during implementations.
- The normative Schema for each static model artefact should use well supported parts of the W3C schema language.
- Use attributes to support the population of PSVI.
- The ITS should support the reuse of components in implementations.
- The depth of nesting in the instances should be a shallow as possible.
- For each static model artefact that will be a UML model defined that expresses the structure of the XML instances, and that is compatible with UML-based case tools.
- The CMET references and Wrapper boundaries should not be transparent in the instance.
- Choices should be transparent in the instance - thus a class should appear in the instance in the same form whether or not it is part of a choice. This is to allow for forwards compatability when choices are introduced into models and to reduce the level of nesting
- Issues
- which UML case tools are supported, and what for?
Specification Walkthrough
Serialisation of HL7 Classes to XML
HL7 Class
Each HL7 class is named using the formal naming conventions defined
HL7 Choice structures
HL7 attribute
HL7 model boundary
Reshaping of RIM based Models
Abstract Serialisation Model
Informal Extensions
Backwards and Forwards Compatability
The use of schema processors
Implementation Issues
Glossary entries
The entries here are words or phrases that are used inthis document and need to be defined in the Glossary