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) |
Charliemccay (talk | contribs) |
||
| Line 5: | Line 5: | ||
*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 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. | *The ITS should allow for the use of W3C schema for validation and message description. | ||
*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 14:22, 1 June 2006
The following is a first cut (by Charlie McCay) at stating what the design principles for the XML ITS were - they have not been reviewed by the XML SIG and should not be taken as definitive. 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.
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.
- 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.
- 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
