Difference between revisions of "TemplateId as a token"
Charliemccay (talk | contribs) |
Charliemccay (talk | contribs) |
||
| Line 24: | Line 24: | ||
It is normal XML practice for such model linking data to be made available in attributes on the element representing the class. | 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 === | === Use QNAMES for model references === | ||
| − | In an XML context model references and references to types are often / normally made using QNAMES, and so it | + | 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 | + | 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> === | === TemplateId as list<cs> === | ||
Revision as of 13:45, 15 May 2007
This page documents an Open MnM Hot Topic, i.e. a methodology issue requiring a resolution from Modeling and Methodology.
Contents
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 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
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>
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
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.
