Bug #477


referencing complex types is not done consistently

Added by Matt Jones over 21 years ago. Updated about 21 years ago.

eml - general bugs
Target version:
Start date:
Due date:
% Done:


Estimated time:


In all modules we import other schemas and use components. Sometimes we define
elements that use a ComplexType, other times we import and use an element that
uses the complex type. We need to go through the modules systematically and
make sure that all inter-namespace references are done in the same way. This
most often involves the ways we use ResponsibleParty, the various coverage
types, and citations, but there are several others too. Check them all and fix

Actions #1

Updated by Matt Jones over 21 years ago

Proposed fix: make a complex type that contains all of the relevant fields in
the schema that is to be imported, then create an element in the current schem
that uses that type. For example, eml-party contains a "ResponsibleParty" type,
which is used to type and element named "creator" that is part of eml-resource.
Similarly, there should be a "Coverage" complex type in eml-coverage, and we
will reference it in an element called "coverage" in eml-resource.

Please be sure that all modules import things using this consistent syntax.

Need to consider this in relation to the use of identifiers and

Actions #2

Updated by Peter McCartney over 21 years ago

There are problems with some software packages (castor for example) that arise
from elements and complex types having the same name (even if distinguished by
capitalization. So we should further distinguish through consisten suffixes.
Currently we seem to be use Base as a suffix for major complex types that
define an entire module and are extended such as resource or entity, and Type
for both simpletypes and minor complex types that are used without extension.
In a few instances, this has let to some odd names like GeometryTypeType, but
they never show up in the instance file anyway.

We should formalize this so we are consistent.

Actions #3

Updated by Matt Jones over 21 years ago

Checked throughout and changed. Now local elements are created that use a type
from the imported module. Done throughout EML, but need to check that it is done
correctly in eml-literature and the spatial modules. Moving milestone.

Actions #4

Updated by Matt Jones about 21 years ago

Looking over the schemas, all of these seem to have been fixed now. Marking as

Actions #5

Updated by Redmine Admin over 10 years ago

Original Bugzilla ID was 477


Also available in: Atom PDF