d.e.d. and d.e.

[Terry Allen <tallen@sonic.net>]

Why a Data Element Dictionary Isn't a Data Element

As an aid to discussion, Len Gallagher asserted that a data element
dictionary (d.e.d.)  is a special kind of data element.  Here's why
I disagree.

A (d.e.d.) contains definitions of data elements (d.e.s).  Part 3,
clause 3.5: “an information resource that specifies,
defines,and lists all relevant data elements.” Strictly
speaking a DTD must be taken with its prose documentation to
constitute a d.e.d.  In the 11179-based DTD, the prose documentation
appears in the same storage entity as the element type definition;
this will also be true of some schemas that use literate programming.
As Len, I think observed Friday, it might be better to consider DTDs
that are broken up into various modules a d.e.d. sets; alternately
we could create a concept for "part of a d.e.d."

But a composite data element contains not definitions of data
elements but *references* to them:

<!ELEMENT game (scissors, paper, rock)>

(with its prose documentation) is the definition of a composite
data element, but the string "scissors" is a reference to a data
element defined elsewhere, possibly but not necessarily in the same
storage entity as the "game" element type.

Now a d.e.d. shares some things with a d.e.: administrative metadata
and metadata about representation.  I may have confused matters
by giving d.e.d.s data element concepts in the DTD; perhaps that
should be "description" instead; its point is not really to support
binding a concept to a representation, as is the case for d.e.s.

But there are other things d.e.s can have that d.e.d.s can't.
I hadn't built out the DTD for data elements, but here's a list
from 11179, Part 3 (Table 2 is a good list):

 - a set of things that we model not on the d.e. definition but
	upon referencing it: obligation, condition, and maximum
	occurrence (this is a fault in 11179)
 - datatype of d.e. values - maximum and minimum size of d.e. 
	attributes. (you can't model this in DTDs but you can in
	schemas)
 - layout of representation of values, such as "two letters followed
	by three numbers" (again, you can't model this in DTDs but
	you can in at least some schema languages)
 - permissible data element values (such as all the ISO 3166 country
	codes; this can be considered an advanced kind of datatype,
	but not everyone sees it that way)

So I don't think it helps to model d.e.d.s as composite d.e.s.
It may help to rename some of the contents of the present
data-element-dictionary element, and perhaps that element doesn't
need multiple name contexts.


regards, Terry