TemplateId as a token

Status

While this reads like an ITS issue, it is best addressed by getting formal acknowledgement from MnM of the special status of these attributes. This will be further discussed in the ITS SIG, and if it is felt that it can be resolved without involving MnM then it will be removed from the MnM hot Topics category

Background

TemplateId is currently defined as a list of II.

TemplateId and TypeId are exceptional RIM attributes in that they convey no semantic meaning, and are just used to bind the instance to a set of constraints to which the instance is claimed to comply.

There has been a suggestion that because of this they should not be included in the RIM, but should be defined in the ITS where such bindings are used. For pragmatic reasons (wanting to keep the documentation together for the convenience of the reader) it is suggested here that these attributes remain in the RIM, but be documented as metadata attributes that do not convey semantic meaning.

templateId and typeId need to be XML attributes

Since their primary function is to bind the instance to the specification, it is suggested that this should be done in a way that makes the best use of the technology in question.

There was some discussion in the ITS SIG in May 2007 (and previously at the Jan 2007 WGM in MnM and ITS) about the difficulty that some implementations were having with such metadata not being available until after the element representing the class has been processed, and that having to read ahead to look at child elements was ugly at best. This has caused such severe concern to development teams in the NHS CFH program that informal extensions have been used to overcome the concerns of implementers.

It is normal XML practice for such model linking data to be made available in attributes on the element representing the class.

Use QNAMES for model references

A qName is a token with a namespace prefix, (eg "xsd:element" or "hl7:document"). It is interpreted by the receiver as a two part identifier comprised of the namespace URI and the token -- the prefix itself is deemed transparent.

In an XML context model references and references to types are often / normally made using QNAMES, and so it has been suggested that these should be used for templateId and typeId. This usage exists in both W3C schema language, and in the XSLT.

This was discussed and rejected in a committee meeting in the Jan 2007 WGM, however new evidence in the form of a W3C Technical Architecture Group article http://www.w3.org/2001/tag/doc/qnameids.html makes it tempting to reopen the question.

However managing the namespace declarations needed for a Qname is more complex that using a simple token. Further we have looked at using multiple namespaces in the XML ITS and found that it is more complex than using a single namespace.

TemplateId as list<cs>

It is therefore suggested that templateId be turned into a list of CS, so that this could be conveyed as a white-space separated list of tokens in an XML attribute on the XML element that represents the class/association in question. The representation of the tempalteIds will be artefactcode#classname.

There may be some issues with the set of characters permitted in CS -- and if so then this will have to be addressed -- at this stage support is sought for the propositions that this is a special-case metadata attribute and that it should be conveyed in attributes in XML-based ITS implementations. At this stage it is proposed that this be added to the New ITS, and that it not be include din the scope for XML ITS R1.1

There's no particular reason why CS should be used; a custom datatype that allows specific handling in the ITS could be used.--GrahameGrieve 19:14, 15 May 2007 (CDT)

agree -- the challenge is to come up with a solution that delivers to the stakeholders that are not happy with the current standard - if a custom datatype can fly in reasonable time and is needed that that is ok by me.

My real worry with this proposal is that II allows root and extension, and people are already using root. Here we will fix root, and allow extension to be used; I don't think this meshes well with existing CDA usage, or with scalability within the planned MnM usage--GrahameGrieve 19:14, 15 May 2007 (CDT)

It seems to me that the proposed MnM model/type identifier scheme does not fit very nicely into the root-extension II model anyway -- named types are charmingly between being an ontology for which one would expect to use codes, and artefacts that define constraints and are maintained in a distributed way, and that one would expect to have identifiers for. Charliemccay 06:16, 16 May 2007 (CDT)

The multi-part identifiers that MnM are proposing include "realm" fragments that will meet the same usecase that II.root is currently being used for -- and in an II all of this new MnM-style identifier will be pushed into either root or extension anyway -- so the current usage of root to provide interesting information about the provenance of the type definition will be (further) deprecated anyway.

It has also been suggested that this can only be resolved when there is an established way to fix the root of an II -- I suggest that this issue should drive us to a good enough solution without the need necessarily for something that solves all identifier problems -- if II is to be used for type bindings (as is currently the case), then we can define a type "iiShort" which is the equivalent of "CS" and that just has a single value, rather than a root+extension. That value is the root of a full II without an extension (though maybe it could also be the extension of an II with a fixed root). It may be simplest to say that MnM must defined an identifier scheme for types that is an "rid" and can be conveyed in the II.root. This could be defined as a universal flavor of II for which the ITS can define a "iishort" XML attribute form just as "cs" is the attribute form of "CS".Charliemccay 06:16, 16 May 2007 (CDT)

drop typeId

as a follow-up proposal, it is suggested that typeId be dropped, and that templateId be used in all situations where a binding to a static model definition is needed.

The rationale for this is that each class inherently carries it's type. Each class must be mapped to a type in the ITS, and each ITS will have it's own way to map type into the representatation. However you look at this, defining typeId as a property on a RIM class is redundant. The only mandated use of TypeId is at the root of CDA, and that could be done otherways. --GrahameGrieve 19:16, 15 May 2007 (CDT)

I am not sure that I agree -- an ITS could easily be conceived that does not do deterministic type binding to the constrained types defined in an RMIM (indeed that is one thing that the New ITS proposals could very well support if abstract serialisation were to be used without conveying the typeId).

However we are both saying that type bindings are different to other semantic attributes, and that the ITS specification should determine how such bindings are conveyed. typeId may only be used to express binding to the type as declared in the most constrained normative HL7 static model (however I rather suspect that this is not the definition of how the attribute is required to be used in CDA). templateId may be used for this, and also for binding to types defined anywhere else in the refinement hierarchy, normative or locally maintained. Charliemccay 05:51, 16 May 2007 (CDT)

Resolution

These things were done as part of the RIM ITS. Input from MnM is not required - this issue is closed.