I copy below a reasonably representative posting from an HL-7 list.
I would say that we will interoperability in our time.
"[Blank] is right about the CNS data type (for v2.5) which will be
used for the CM data type. It was created as a CN "Simple" to be
used where CN was used as a component within a data type. The CN
became complex and could no longer be used within a data type. The
NDL data type was one such data type. We originally used CNH (for
historical) but (I think) the ARB had us change the name. It made
sense and there was no 'rule' about the data types and segments
having the same name.
In v2.xml, the segment would use <CNS> as the element with each field
as a child elements called <CNS.1>, <CNS.2>, etc. The fields of the
NDL data type would have a child element <NDL.1> which would have
child elements <CNS.1>, <CNS.2>, etc. From a heirarchical
standpoint, there would not be an issue. The issue is the method by
which the dtd and schema are defined.
In fields.dtd, the element OBR.32 is defined using the entity
OBR.32.CONTENT which is defined using the entity NDL. In
datatypes.dtd, the entity NDL is defined as
"(NDL.1?,NDL.2?,NDL.3?,NDL.4?,NDL.5?,NDL.6?,NDL.7?,NDL.8?,NDL.9?,NDL.10?,NDL.11?)".
NDL.1 is defined using the entity NDL.1.CONTENT which is defined
using the entity CN (erroneously - should be CNS, part of CM
"replacements" that Kai is working on). CNS "would be" defined as
"(CNS.1?,CNS.2?,CNS.3?,CNS.4?,CNS.5?,CNS.6?,CNS.7?,CNS.8?,CNS.9?,CNS.10?,CNS.11?,)".
The message .dtd brings in the fields.dtd and the fields.dtd brings
in the datatypes.dtd. At that point, the fields CN1.1 thru CNS.11
would be defined like the CNS data type components."
