46 lines
1.3 KiB
Plaintext
46 lines
1.3 KiB
Plaintext
---+++ AbcdConcept1022
|
|
|
|
---+++++ Identifier
|
|
|
|
<verbatim>DataSets/DataSet/Units/Unit/Gathering/Altitude/MeasurementOrFactAtomised/Parameter</verbatim>
|
|
|
|
|
|
|
|
---+++++ Group
|
|
|
|
MOF
|
|
|
|
---+++++ Subgroup
|
|
|
|
MOF-Gathering
|
|
|
|
---+++++ Full Name
|
|
|
|
Parameter (n/a)
|
|
|
|
---+++++ Documentation
|
|
|
|
This is set to "Altitude" by definition for measurements of altitude.
|
|
|
|
---+++++ Content
|
|
|
|
This is set to "Altitude" by definition for measurements of altitude.
|
|
|
|
---++++ Recommended or Prescribed Values
|
|
n/a
|
|
|
|
---+++++ Example Value
|
|
n/a
|
|
|
|
---+++++ Example Explanation
|
|
n/a
|
|
|
|
---+++++ Reviewer
|
|
Berendsohn 16 Apr 2005
|
|
|
|
---++++ Editorial Notes
|
|
|
|
Is the generic description for parameter I found in the schema ok for this element? Should I take out the examples like width, circumference etc.?
|
|
|
|
The parameter element makes sense only where the measurmentOrFact type is used to describe "open" measurements, where the users decide what it is what is measured. Altitude etc. are a special case, the parameter is actually always altitude. A solution to this would be to exclude this from the MoF and put it into an extension, only used when general measurements are asked for. I added this to the Schema discussion page. For the time being, the above (English?) can serve as a template for similar cases (depth etc.).
|