Project

General

Profile

Actions

Bug #638

closed

request for id/ref in attributeDomain

Added by Matt Jones about 20 years ago. Updated about 20 years ago.

Status:
Resolved
Priority:
Immediate
Assignee:
Category:
eml - general bugs
Target version:
Start date:
10/17/2002
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
638

Description

Barbara Benson representing NTL LTER site made the following request:

3) Here is a suggested addition to EML2. When describing an
enumerated domain, the same code/definition pairs are used repeatedly in
an eml document. Could an id and reference be allowed in the attribute
domains?

My feeling is that this is an excellent idea. I think this would be extremely
common, and we should accomodate her request. The instance docs would largely
be the same except for the possibility of having to deal with a reference
substition.

Below is an example snippet that Barbara provided as they would like to use this
feature at NTL. Note that they reference the "enumeratedDomain" field, whereas
I htink we should be referencing the "attributeDomain" field instead so that any
of the domain types can be shared. It would make domain comparisons among
attributes very easy. Here's her example:

<attribute>
<attributeName>FLAG_AVG_AIR_TEMP</attributeName>
<attributeDefinition>data flag for air temperature</attributeDefinition>
<unit>
<customUnit>dimensionless</customUnit>
</unit>
<measurementScale>nominal</measurementScale>
<attributeDomain>
<enumeratedDomain id="enum.METFLAG" scope="document">
<codeList>
A
<definition>Data logger off</definition>
A?
<definition>Data logger off an indeterminate number of
hours</definition>
An
<definition>Data logger off n hours; daily averages may be in
error</definition>
B
<definition>Data logger off</definition> C
<definition>Sensor off; missing value reported</definition>
D
<definition>Sensor malfunction produced bad values; values set
to missing;</definition>
E
<definition>Sensor noisy; values of uncertain quality</definition> F
<definition>Sensor calibration error; correction factors have
been applied.</definition>
G
<definition>Sensor error; estimate made based on hourly
averages.</definition>
H
<definition>Data suspect; values outside of expected
range</definition> I
<definition>Estimated from combining more than one record for
the day</definition>
J
<definition>Estimated from another met station.</definition>
K
<definition>Sensor malfunction produced bad values: data of
limited use.</definition> L
<definition>Non standard routine followed</definition>
</codeList>
</enumeratedDomain>
</attributeDomain>
</attribute>
<attribute>
<attributeName>FLAG_AVG_DEWPOINT_TEMP</attributeName>
&lt;attributeDefinition&gt;data flag for dew point temperature
&lt;/attributeDefinition&gt;
&lt;unit&gt;
&lt;customUnit&gt;dimensionless&lt;/customUnit&gt;
&lt;/unit&gt;
&lt;measurementScale&gt;nominal&lt;/measurementScale&gt;
&lt;attributeDomain&gt;&lt;enumeratedDomain&gt;
&lt;references&gt;enum.METFLAG&lt;/references&gt;
&lt;/enumeratedDomain&gt;&lt;/attributeDomain&gt;
&lt;/attribute&gt;
Actions #1

Updated by Peter McCartney about 20 years ago

I agree that it makes sense to do it at attributeDomain rather than each of the
options below it.

I cant think of too many datasets we have where a particularly lengthy
enumeration list is used more than once without creating a table as part of the
dataset to contain the enumeration, but i suppose there are people who never
build such tables in their datasets, or for some reason dont include them in the
release.

Actions #2

Updated by Matt Jones about 20 years ago

DONE. All attribute Domain elements can now be referenced to allow for this
sort of repeated use of the same domain among multiple attributes.

Actions #3

Updated by Redmine Admin over 9 years ago

Original Bugzilla ID was 638

Actions

Also available in: Atom PDF