This wiki has undergone a migration to Confluence found Here
Difference between revisions of "XML ITS design principles"
Jump to navigation
Jump to search
Charliemccay (talk | contribs) |
Rene spronk (talk | contribs) m (add clarifying link for PSVI) |
||
| Line 10: | Line 10: | ||
*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. | *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. | ||
*The ITS should allow for the use of W3C schema for validation and message description. | *The ITS should allow for the use of W3C schema for validation and message description. | ||
| − | *Use attributes to support the population of 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. | *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. | ||
*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 | ||
Revision as of 20:07, 5 June 2006
As the XML ITS is maintained, and other ITS specifications are developed it seems that it would be useful to have a baseline of the principles that were followed for the first HL7v3 ITS.
These were approved by INM 5/6/06 on a conference call as a true account of the design principles that were used for XML ITS.
The design principles that were followed to produce the release 1 XML ITS were:
- 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.
- 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.
- 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
