Bug #1031
closedenumeratedDomain doesn't define value order for ordinals
0%
Description
Ordinal scale measurements have a discrete list of values with a specific
ordering of those values. EML does not provide a mechanism for specifying what
this order should be. We need to add this feature. Two possible approaches
come immediately to mind:
1) Redefine the "ordinal" element to state that values should be listed in the
code/definition pairs in ascending order. This has the disadvantage of not
being backwards compatible (ie, some eml-2.0.0 documents might not list them in
this order, and interpreting them in the context of newer versions of eml will
lead to incorrect ordering.
2) add an optional attribute to "codeDefinition" named "order" that is of type
long integer, and make its value correspond to the order of the items. For
example, for LOW, MEDIUM, HIGH, the order attribute might be "LOW=1, MEDIUM=2,
and HIGH=3. This is backwards compatible because it is optional.
I currently see no disadvantages to this approach (2) and so that is what I
recommend at this point. Feedback appreciated.
Updated by Saurabh Garg over 20 years ago
Added an optional attribute to "codeDefinition" named "order" that is of type
long integer
Updated by Matt Jones over 20 years ago
Also added an optional element called 'orderAttributeReference' to the
entityCodeList that points at a column containing an ascending index that
specifies the code order, analogous to the 'order' attribute in the
codeDefinition element.