Move project element to top-level
This is a request to move the <project> element to the root-level of the EML
schema. Currently, the <project> element (type="proj:ResearchProjectType") is
embedded within the <dataset> element.
The NCEAS Ecosystem-Based Management (EBM) program is creating a registry of EBM
projects. Projects in the EBM program relate a project to the products
generated, which include citations, URI references, and datasets. No products
are required to have a valid project (since projects may be in early stages of
development or lack publications). Ideally, this could be stored in EML as one
main EML document for the project, citations, URIs, and then additional EML
documents for each dataset.
Updated by Peter McCartney over 17 years ago
I dont object as i think this would be a backward-compatible change. However,
i think it's a patch to what is really desired - to be able to manage and
exchange metadata in more atomic units than whole eml documents. I can easily
forsee similar requests to treat spatial reference, party, attributes, etc as
"root" elements (they arent really root, are they?). I think we need to begin
some longer term thinking about eliminating the <eml> tag itself which would
let content for each xsd file in eml potentially be a root element.
If we continued to support the eml tag but just agreed it was ok to make xml
documents that validate only to eml-project or eml-party, I think even that is
technically still backwards compatible.
Updated by Margaret O'Brien over 14 years ago
This bug is related to the discussions of what the root element "eml" describes, and whether resources can be collections in addition to individual documents. A solution may involve changes to other modules. See bugs #2076, #1128, #3503
One other note:
If project.xsd were to move to a top-level module, then it would make use of the resourceGroup. The change would affect all existing EML documents because the structure for including party in project.xsd is with the <personnel> element, an extension of the PartyType (with the added child, <role>):
In a resourceGroup, <personnel> is not available. The only element that has a <role> child is <associatedParty> so project/personnel trees embedded in (e.g.) datasets, will need to be transformed to