Project

General

Profile

Bug #1031

enumeratedDomain doesn't define value order for ordinals

Added by Matt Jones over 17 years ago. Updated about 16 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
eml - general bugs
Target version:
Start date:
04/08/2003
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
1031

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.

History

#1 Updated by Saurabh Garg about 16 years ago

Added an optional attribute to "codeDefinition" named "order" that is of type
long integer

#2 Updated by Matt Jones about 16 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.

#3 Updated by Redmine Admin over 7 years ago

Original Bugzilla ID was 1031

Also available in: Atom PDF