Normative XML ITS Schema

During the discussion of the proposed UML ITS it was suggested that in order to ease the implementation burden a set of normative schema/schematron could be created as part of (a new release of) the XML ITS. The advantages/disadvantages of this approaches have yet to be discussed.

Summary

This Summary was prepared from the 20061113 INM Telcon discussion (see Talk:Normative XML ITS Schema) by Grahame Grieve

• We acknowledge that the current situation is frustrating for the implementers as there is no final statement of what is the acceptable wire format, and it is hard to determine what is actually correct.
• we believe that in spite of it's shortcomings, W3C XML schema is the most appropriate form to make this statement. It stands as human and computer usable documentation
• we do not currently give any formal status to the schemas that we publish. We do not properly document why do not do this.
• we would like to give a formal status to the current schemas, so that implementors know how much to rely on them, and what not to rely on them for
• we do not want to make the schemas normative in the sense that each schema is subject to ballot and comments on models can be made against the schemas
• but we would like to give the schemas a formal status and appropriate (and documented) procedures to provide assurance that they have real meaning.
• we are still searching for the appropriate term to give implementation artifacts derived from normative artifacts. (some discussion below)
• we also acknowledge that schema can never provide complete validation, and that we need to clearly document the limitations of this

But there is two real problems with giving the schemas a more formal basis:

• the set of normative instances described by the XML ITS (often called "the wire format") is not properly able to be described by schema. This is discussed further below. This is the big problem in giving the schemas a more formal basis (whatever we call it)
• we also know that there is various differences in the schema validation tools

The UML ITS may be the the only real way to solve the problem. The UML ITS has been designed from scratch to deliver schemas that describe the wire format, and to deliver schemas that are interpreted as uniformly as possible.

This may become a solution for this problem for the XML ITS if the UML ITS becomes R2 of the XML ITS. At the present time, in some configurations the UML ITS is very similar to the UML ITS, and this is still something to consider.

Naming Problem

We do not know what name to give to our desired status for the schemas. Some possibilities discussed:

• conformant
• official
• normative
• published

An alternative approach is the leave them as normative and just clearly document their status and how we manage them.

Action: Contact HQ for whether ANSI has some appropriate terms. (done, awaiting comment)

From the CDA specification:

A conformant CDA document is one that at a minimum validates against the CDA Schema, and that restricts its use of coded vocabulary to values allowable within the specified vocabulary domains. However a computer cannot validate every aspect of conformance. The focus of this section is to highlight these aspects of CDA that cannot be machine validated - particularly those aspects related to the CDA human readability requirements.

Charlie proposes that we adopt/adapt this language in the ITS Specification and that this will give the schemas the status that we desire. Note that we may need to clarify the effect of schema tools when checking validating instances against schema.

Differences between the XML ITS wire format and the schemas

Schema do not properly describe the wire format that the XML ITS describes. In some areas, instances that are conformant will fail schema validation and in others, instances that are not conformant will pass schema validation.

Obviously, there is many things that the schema do not validate. Essentially, the schema validate the XML and the format of the data itself. The schema do not - and never will - validate the semantic correctness of the instance. But in the things the schema does, we need to make the schema do them correctly before we can give the schema an enhanced status.

Co-occurance constraints: The schema do not know the co-occurance constraints. This could be fixed in the XML ITS.

xsi attributes: Schema based processing engines - which we would need to make work - this is a big part of making the schemas normative - will consume and produce xsi: attributes such as type, nil, schemalocation etc. For the moment:

• we have banned schemaLocation
• we make no comment on xsi:nil
• we make very confusing comment on xsi:type

We appear to reuse the xsi:type mechanism for the HL7 type representation. This is not clearly documented, but it is highly implied. The biggest problem with using schema is that the behaviour of xsi:type follows the schema type rules, and we have been unable to match the behaviour of the schema type rules and the HL7 type rules, particularly in the datatypes area.

todo: complete this section