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.

Discusion

• I guess the major question is the meaning of the ITS being normative. If it means instances must conform to the schema to be conformant, that's fine. (Though I believe there may be one or two places where the schema may still complain about instances that are technically conformant.) On the other hand, if it means that conforming with the schema is sufficient, that would be a problem. It would also be a problem if it actually required implementers to use the schemas in any way (either in the construction or validation of instances).
• The question that I have is if we make the ITS schemas normative, why stop there? Why should those schemas be normative while others are not?
  • The issue is that implementers currently have nothing to implement against. We describe what XML instances are valid (that's what the XML ITS does) and give them schema. But we (as HL7) give no guarantees that those schema are correct. From an implementer's standpoint that's no good.
  • An implementer may use any schema they want - but having normative schema would allow them to test their instances against those normative schema. So this is not about the structure of the normative schema, but the ability to use them as a "benchmark" in testing and development.
  • The concept of a normative implementable model came up during discussions of the new UML ITS, see UML ITS and UML ITS Technical. It is a key element of that ITS. Therefore it nees to be examined if the concept can be retrofitted into the XML ITS.
  • While the idea of a Reference schema is good, the idea of a Normative one is not so good. It prevents people from coming up with a simpler to understand variant of the machine generated schema and it prevents people for extending or restricting the schema for specific purposes.

Discussion during the 2006113 INM TelCon

• Doug: support making them normative, irritating that there is no support. Tony agrees.
• Grahame: within UML ITS. Implementers should have norm artefacts. Trouble is that schema describe same wire format as XML ITS. XML ITS is not written for schema. Can't make schema normative, then turn around and state schema are not correct. Schema can't be enough, but have to be correct. Lots of stuf out of schema specification like xsi:nill. In UML ITS describe actually what goes on the wire. Again not all you need to know. We design wire-format differently in order to make schema normative. Interetsed in whether "normative" is correct word. Normative means schema are subject to ballot. We don't want that. What we want is for implementers to be able to "hang their hat on" some schema set.
• Doug: is there analysis of what schema can't describe? Grahame: not written up. Doug: schema not ridgid enough? Grahame: having sche carries implications for wire format. Sch describe wire format. Cant ahve areas where areas are wrong. Can have areas where they are incomplete. reasonable for implementers to say that instance validates against schema. Schema type handing system is different in concept to v3 typing system. we dont describe differences. If you use schema based toolkit you trip over differences like xsi:nil.
• Skirmantis: schema should be designed for extensability. Current schema dont allow for diff namespaces. Grahame: need to do in UML ITS. Skirmantas: Schema should allow attributes from other namespaces. Grahame: can extend attributes, can't extend datatypes. Schema dont have to describe them. Skirmantas: if schema are official/normative, should have extenibility build in.
• What does it mean to make it normative. Where should it be used? Grahame: can use in implementation, dont have to. Describes wire format. Need to be clear about it and avoid interpretation that any instance that validates against schema is a valid v3 instance.
• "Normative" is the wrong word. Call them "Official"? "HL7-Sanctioned"? Stand behind them. Won't get tripped on if you implement these. Call them "Supported"?. "Official Reference Schema"? If you fix schema then you change wire format. Can't change them that freely anymore once balloted. Currently schema can be changed at will, as long as we have same wire format. How much a price are we willing to pay? Need to stay just short of being normative. Don't want ballot comments on individual schema nor schema construct principles. Call them "Conformant?"