XML ITS R1 schema change management

Introduction

This is a document that is maintained by the ITS SIG. Change requests to the XML schema are managed in this document. Please add any issues that you have with the design of the schemas to it.

Tooling errors

Bugs in the schema generator should be reported directly to the tooling committee that is responsible for maintaining the schema generator.

There is a separate document for maintaining XML ITS R1 schema tooling issues

Process

All changes to the XML schema since the production of the 2006 normative edition should be documented on this page.

Anyone may add an issue to this page, and provide a suggested solution. The change must then be notified to the XML list, and if there is any sustained objection on the list to the change, then the proposal must be discussed on an INM or XML SIG conference call to obtain a resolution.

This document will be reviewed at each WGM by INM. This is the final step in the approval of a change, though when there is an urgent requirement changes can be made and published before this has been done (though they MUST be notified to the XML SIG list.

The status of each issue should be includeed as the first line of the issue. If there is a planned next step that shoudl also be included. Possible states are: "Draft", "Notified", "WGM approved", "Done, WGM approved", "Done, WGM review needed". Once there is a concrete proposal the XML SIG list should be notified, and the status changed to "Notified". At that point a toolsmith can make the change and the change proposal will be reviewed at the next WGM (these can happen in either order - with the change being rolled back if there are WGM objections to it).

Issues / Change Proposals

Null flavor disallowed on mandatory classes and attributes

status: Notified

The nullFlavor attribute should be excluded from the attributeGroup that is referenced for mandatory classes and attributes. This proposal has been notified to the XML SIG list Charliemccay 06:04, 21 Jun 2006 (CDT)

xsi:nillable be added wherever needed

Status: Closed

This will allow the use of xsi:nil in the instance, which in turn will allow the mandatory contents of null classes to be left out. Charliemccay 05:24, 22 Jun 2006 (CDT) This should also be considered for the datatypes where there are non-optional components

--MatthewStephens 09:08, 26 Jun 2006 (CDT) Nillable is generated by the schema generator wherever it is needed

xsd:any in ED

Status: Draft -- awaiting a concrete proposal

The schema currently allows no markup in an ED -- which is wrong - but we assumed that in practice someone using markup in ED would want to tweek the schema to allow the appropriate content. (There is no comment to this effect in the distributed schema however. Charliemccay 05:24, 22 Jun 2006 (CDT)

The options that we considered included just allowing other namespaces, or putting the thumbnail and reference elements as globally declared elements in the HL7v3 namespace, with a stated rule that they can only be used in ED. This would then let us have xsd:any namespace="##any" in the ED datatype.

This was raised agin by Ravi on the list as follows Charliemccay 05:42, 4 May 2007 (CDT) 2) XML ITS for ED says Content: ( reference, thumbnail, (#PCDATA | any) ). Looking into the schema the sequence is

<xs:sequence>

<xs:element name="reference" type="TEL" minOccurs="0"></xs:element> <xs:element name="thumbnail" type="thumbnail" minOccurs="0"/> </xs:sequence>

There is no reference to any elements that come from other namespace. The schemas sequence should have been

<xsd:sequence>

<xsd:element name="reference" type="TEL" minOccurs="0"></xsd:element> <xsd:element name="thumbnail" type="thumbnail" minOccurs="0"/> <xsd:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence>

3) The same problem exists in "thumbnail" within ED whose Content: ( reference, (#PCDATA | any) ).

* -> Where is the conformance of XML ITS datatypes against the Abstract Datatype Specification ensured ?. How many more issues like this exist in the datatypes XML ITS schema.

A response from Charlie McCay was as follows: the following text is from the XML ITS datatypes [1]

[1] http://www.hl7.org/v3ballot/html/infrastructure/itsxml/datatypes-its-xml.htm#dtimpl-ED

"Markup contained in an ED can come from any namespace other than the HL7 V3 namespace (urn:hl7-org:v3) without restriction. Additionally, any element in the HL7 namespace that represents an interaction or the root of a CDA document may also appear. The reason for this restriction on elements from the HL7 namespace is to help support those who choose to do optional XML Schema processing. It would not be possible to write a schema definition that would allow arbitrary content from the HL7 namespace since that would result in a violation of Schema Component Constraint: Unique Particle Attribution."

Note that because ED allows elements in the HL7 namespace, a simple ##other is not correct -- the decision at the time was that it was better to have a schema that was incomplete than one that had ##other, but did not allow hl7 namespace errors. I agree that the schemas should be improved in this area -- with a comment added to explain the issue, and the addition of the ##other so that for many situations the schemas will work directly.

datatypes-voc-datatypes recursion

Ravi: There is recursion in the schemas datatypes->voc->datatypes. This should be avoided if possible

Agree that this should be avoided where possible, however in this case there is a circular dependancy and so it is not avoidable. It is supported by the schema spec, though recognised that some tools do/did not support it weel. Any suggestions for simplification would be welcome -- some effort went into trying to avoid this at the time that the XML ITS R1 schemas were initially developed. Charliemccay 05:52, 4 May 2007 (CDT)