This wiki has undergone a migration to Confluence found Here
Difference between revisions of "New ITS Guide"
Jump to navigation
Jump to search
Charliemccay (talk | contribs) |
Charliemccay (talk | contribs) (added design principles from XML ITS R1) |
||
| Line 13: | Line 13: | ||
== Overview == | == Overview == | ||
=== Introduction and Scope === | === Introduction and Scope === | ||
| − | This document describes the rationale for the decisions taken when | + | 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 the simplicity of the model-instance transform the instances should be as small as possible. Thus XML attributes were used for datatype components. | ||
| + | *The ITS should define the set of valid instances for a V3 artefact, NOT the schema that must be used. This is to allow for stability of the instances as schema techology improves, and also allows for the use of different schema for different uses. (see below) | ||
| + | *The ITS should allow for the use of W3C schema for validation and message description. | ||
| + | *Use attributes to support the population of [http://en.wikipedia.org/wiki/PSVI PSVI]. | ||
| + | *CMET references and Wrapper boundaries should be transparent in the instance. Thus it should be possible to re-package the way that an interaction is defined by mergeing two wrappers, without that affecting the instances. (see below) | ||
| + | *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 | ||
== Specification Walkthrough == | == Specification Walkthrough == | ||
=== Serialisation of HL7 Classes to XML === | === Serialisation of HL7 Classes to XML === | ||
==== HL7 Class ==== | ==== HL7 Class ==== | ||
| + | Each HL7 class is named using the formal naming conventions defined | ||
==== HL7 Choice structures ==== | ==== HL7 Choice structures ==== | ||
==== HL7 attribute ==== | ==== HL7 attribute ==== | ||
Revision as of 10:38, 9 February 2007
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 the simplicity of the model-instance transform the instances should be as small as possible. Thus XML attributes were used for datatype components.
- The ITS should define the set of valid instances for a V3 artefact, NOT the schema that must be used. This is to allow for stability of the instances as schema techology improves, and also allows for the use of different schema for different uses. (see below)
- The ITS should allow for the use of W3C schema for validation and message description.
- Use attributes to support the population of PSVI.
- CMET references and Wrapper boundaries should be transparent in the instance. Thus it should be possible to re-package the way that an interaction is defined by mergeing two wrappers, without that affecting the instances. (see below)
- 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
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
