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 1: | Line 1: | ||
| − | The following is a first cut at stating what the design principles for the XML ITS were - they have not been reviewed by the committee 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 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 committee 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 design principles that were followed to produce the release 1 XML ITS were: | ||
| Line 7: | Line 7: | ||
*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. | + | *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 15:11, 30 May 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 committee 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 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
