This wiki has undergone a migration to Confluence found Here
R2 XML ITS structures
Jump to navigation
Jump to search
Contents
- 1 A sentence needs to be added describing the root element of a batch transmission. (STR-001)
- 2 XML Representation of collection type and nullFlavor (STR-002)
- 3 Language - review vocab binding in XML (STR-003)
- 4 Review way that xml spec handles removed properties (STR-004)
- 5 What to do about xsi:type on RTO implementations (and why isn’t RTO in the generics) (STR-006)
- 6 which XML attributes can be used (xml:base) (STR-008)
- 7 Associations originating from a choice rather than from a specialized class in the choice are pushed into the element model of each of the specialized classes. Need to show an example of this (including RMIM/HMD) (STR-009)
- 8 XML representation of RIM-level associations - i.e. how can a generic RIM processor distinguish source->target vs. target->source relationships or player vs. scoper associations (STR-010)
- 9 ITS needs to indicate how cardinality is determined (based on a combination of 'optionality' as well as base cardinality) (STR-011)
- 10 Need guidance on when xsi:type should be populated where it's known from the message schema, but not necessarily known when parsing from a RIM perspective (STR-012)
- 11 How is the root element name determined for structured documents? (They don't have an interaction id.) (STR-013)
- 12 Move away from talking about rows and columns in the HMD and use HL7 static model instead (STR-014)
- 13 Standardise the complex type names for classes (STR015)
A sentence needs to be added describing the root element of a batch transmission. (STR-001)
XML Representation of collection type and nullFlavor (STR-002)
Language - review vocab binding in XML (STR-003)
Review way that xml spec handles removed properties (STR-004)
What to do about xsi:type on RTO implementations (and why isn’t RTO in the generics) (STR-006)
which XML attributes can be used (xml:base) (STR-008)
Associations originating from a choice rather than from a specialized class in the choice are pushed into the element model of each of the specialized classes. Need to show an example of this (including RMIM/HMD) (STR-009)
XML representation of RIM-level associations - i.e. how can a generic RIM processor distinguish source->target vs. target->source relationships or player vs. scoper associations (STR-010)
ITS needs to indicate how cardinality is determined (based on a combination of 'optionality' as well as base cardinality) (STR-011)
Need guidance on when xsi:type should be populated where it's known from the message schema, but not necessarily known when parsing from a RIM perspective (STR-012)
How is the root element name determined for structured documents? (They don't have an interaction id.) (STR-013)
Move away from talking about rows and columns in the HMD and use HL7 static model instead (STR-014)
Standardise the complex type names for classes (STR015)
xsi:type may be used in the instance, and while the XML ITS datatypes defines the type names for the datatypes, the structures document does not provide names for the types of the types of associations though these are named in the schema. Thus there are implementations that use the complex type names from the schema, and these may clash with names used in different schemas to validate the instances. Proposal: the complex type names become normative in R2, so that if xsi:type is included in the instance, it will be safe.
