This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

TemplateId as a token

From HL7Wiki
Jump to navigation Jump to search

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)
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)

drop typeId

as a follow-up proposal, it is suggested thattypeId 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)