Bug #1561


EML Attribute Page Editor doesn't handle some XML Schema attributes/elements correctly

Added by Chris Jones about 20 years ago. Updated almost 18 years ago.

In Progress
morpho - general
Target version:
Start date:
Due date:
% Done:


Estimated time:


In morpho 1.5.1, the data Package Wizard creates EML2.0.0 packages without
inserting the (optional) enforced="yes|no" schema attribute in the nominal and
ordinal measurement scale enumeratedDomain elements. If packages are then
edited with the Tree Editor, the enforced="yes|no" attribute is inserted
(confirmed by Sid).

Subsequent edits of the column metadata with the Data --> "Edit Column
Documentation" menu incorrectly brings up the Tree Editor for Nominal and
Ordinal columns. calls setPageData() in order to populate
the fields found in the OrderedMap of XPATH strings and values. All of the
elements in the map are handled, but the XML
attributes are not, such as the enforced="yes\no" attribute.

In, attributes are discarded with:

map.remove(xPathRoot + "/@id");
map.remove(xPathRoot + "/@scope");

and so the 'enforced' attribute can be discarded with:
map.remove(xPathRoot +

However, this seems like a hack, since at some point down the line the
'enforced' field should be presented as a check box or another widget.
Likewise, other XML attributes should be handled as to not discard the information.

Actions #1

Updated by Matthew Brooke about 20 years ago

the map.remove() should be part of the setPanelData() method for the
enumeratedDomain subpanel, not the setPageData() method for the top level
attributePage. That way, it is located logically where the relevant metadata
would be handled (or will be handled if, in future, a checkbox is ever added
for this attribute, as chris mentioned above.)

Actions #2

Updated by Chris Jones about 20 years ago

As an addition to this bug, some elements may have been overlooked as well:


is left over in the OrderedMap, and so the Tree Editor is enabled rather than
the Attribute Editor

Actions #3

Updated by Chris Jones about 20 years ago

One more attribute not handled and left in the OrderedMap:


Actions #4

Updated by Dan Higgins about 20 years ago

An alternative 'fix' would be to change the way the tree editor handles xml
attributes. Right now it inserts suggested value wheng available and trims those
with no information when saving. The template could be changed to not insert
anything into all optional attributes. Unfortunaely, there is currently a bug in
the tree editor in that it does not 'know' whether xml attributes are optional
or required.

Actions #5

Updated by Chris Jones almost 20 years ago

I've changed both and to handle the
/@id, /@scope, /@system, /@enforced, /@typeSystem attributes. We still need to
address the missingValueCode/codeExplanation element mention previously. Also,
we need to check both and for similar
bugs where there are not placeholders or widgets to handle the various XML

Actions #6

Updated by Chris Jones almost 20 years ago

I've added placeholders for the <missingValueCode> sub elements:
and <codeExplanation>. This changed the setPageData() and getPageData methods.

Actions #7

Updated by Saurabh Garg almost 19 years ago

Trying to summarize the state of this bug based on above comments and cvs
messages for commits done by Chris.

1. "This fix brings up another bug: <enumeratedDomain> is repeatable, but the
AttributePage class is only set up to handle the first instance of this element
by using the NominalOrdinalPanel, IntervalRatioPanel, etc. "
This should be added as a bug if not added already

2. "Also, we need to check both and
for similar bugs where there are not placeholders or widgets to handle the
various XML attributes."
Will add placeholders for @id to and

3. "Still need to deal with coverage and method. This fix also only supports a
single missing value code/codeExplanation pair for the attribute in question.
When this is converted to a widget in the interface, we should handle the case
were missingValueCode elements repeat."
We do not cover a lot of the eml fields in the wizard screens. This is true
for all the wizard screens. This is because wizard screens were kept simple and
only used for gathering data which is required. Hence, though having widgets
for coverage and method information would be useful, there might be some
discussion on which fields should be included in the screens. Same is true for

I think placeholders for attributes like id,scope etc are good to have. But any
field that has relevant data in it should be displayed to the user. Thats where
tree editor comes in - even though it is not as user friendly as wizard

Actions #8

Updated by Redmine Admin about 11 years ago

Original Bugzilla ID was 1561


Also available in: Atom PDF