TemplateId as a token
TemplateId is currently defined as a list of II.
TemplateId and TypeId are exceptional 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 about the difficulty that some implementations were having with such metadata not being available until after the element representing the cass 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
In an XML context model references and references to types are often / normally made using QNAMES, and so it is suggested that these should be used for templateId and typeId.
This was discussed and rejected in a committee meeting in Jan 2007, however new evedence in the form of a W3C Technical Architecture Group article http://www.w3.org/2001/tag/doc/qnameids.html makes the case far stronger that it was when presented.
TemplateId as list<cs>
If for some reason using QNAMES is not acceptable, then a fallback suggestion would be 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
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.