This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "New ITS Guide"

From HL7Wiki
Jump to navigation Jump to search
(added design principles from XML ITS R1)
(→‎Design Principles: changes from XML ITS R1)
Line 18: Line 18:
 
*The instances should be pleasing to the eye of a human reader.
 
*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
 
*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.
+
*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, 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 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 ITS should allow for the use of W3C schema for validation and message description.
+
*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 [http://en.wikipedia.org/wiki/PSVI PSVI].
 
*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)
+
*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
 
*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 ==  
 
== Specification Walkthrough ==  
 
=== Serialisation of HL7 Classes to XML ===
 
=== Serialisation of HL7 Classes to XML ===

Revision as of 10:51, 9 February 2007

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

Questions for Publishing

Retrieved from "https://wiki.hl7.org/w/index.php?title=New_ITS_Guide&oldid=11258"