Bug #3239
closedmetacat using illegitimate versions of EML schemas
0%
Description
Metacat should ship with EML 2.0.0 and EML 2.0.1 schemas preinstalled. Upon inspection, it seems we are using modified versions of these that include files from the HEAD of the EML CVS.
A concrete example is eml-resource.xsd. According to the tags:
RELEASE_EML_2_0_1_UPDATE_6: 1.79
RELEASE_EML_2_0_1_UPDATE_5: 1.79
RELEASE_EML_2_0_1_UPDATE_4: 1.79
RELEASE_EML_2_0_1_UPDATE_3: 1.79
RELEASE_EML_2_0_1_UPDATE_2: 1.79
RELEASE_EML_2_0_1_UPDATE_1: 1.78
RELEASE_EML_2_0_1: 1.78
This indicates that we should be shipping 1.78 with the metacat release for EML 2.0.1. But in the production version, it contains 1.79. I suspect this is being picked up from the UPDATE_5 tag, which is wrongly tageed at version 1.79.
This needs to be fixed ASAP, and we need to notify LTER of the problem because they will likely have a bunch of invalid documents once we start enforcing the 2.0.1 schema properly.
Updated by Jing Tao about 16 years ago
Here are some thoughts:
1)
For short term solution, we can check out a RELEASE_EML_2_0_1 version eml and manually copy those .xsd files to web-context/schema/eml-2.0.1 directory.
Those files are need to be copied (total 24 files):
eml-access.xsd eml-coverage.xsd eml-documentation.xsd eml-methods.xsd eml-project.xsd eml-software.xsd eml-spatialVector.xsd eml-view.xsd
eml-attribute.xsd eml-dataset.xsd eml-entity.xsd eml-party.xsd eml-protocol.xsd eml-spatialRaster.xsd eml-storedProcedure.xsd eml.xsd
eml-constraint.xsd eml-dataTable.xsd eml-literature.xsd eml-physical.xsd eml-resource.xsd eml-spatialReference.xsd eml-text.xsd stmml.xsd
I will try this first in dev, then in knb if everything looks good in dev.
2)
For long term solution, we need to use different tags for eml 2.0.1 xsd files and xsl files in metacat build.xml. RELEASE_EML_2_0_1 for schema and RELEASE_EML_2_0_1_UPDATE_* for style sheets. So I will propose two properties name here:
eml2_0_1-schema-tag=RELEASE_EML_2_0_1
eml2_0_1-style-tag=RELEASE_EML_2_0_1_UPDATE_*
During metacat build process, eml201 will be checkout first as eml2_0_1-schema-tag, and xsd files will be copied to the schema dir. Then eml201 checkout will be update by eml2_0_1style-tag, and xsl files will be copied to style sheet dir.
Currently we don't ship eml-200 style sheets with metacat. It uses eml201 one. So we wouldn't add new style property for eml200.
Updated by Jing Tao about 16 years ago
Okay, i manually copied RELEASE_EML_2_0_1 xsd files to schema dir in dev. I also backed up the old files. Callie and I will test against it.
Updated by Jing Tao about 16 years ago
Callie inserted a new document into dev and the "system" attribute of "references" is gone. I also tried to insert a document which is existed eml201 instance containing "system" attribute in "reference", it failed - [attributes] of element 'references' must be empty.
I didn't see any unknown problem to do this in knb production server.
Updated by ben leinfelder about 16 years ago
does this mean that Metacat was generating the extra attribute and not Morpho?
Updated by Jing Tao about 16 years ago
ben, yes. see bug http://bugzilla.ecoinformatics.org/show_bug.cgi?id=1601
Updated by Jing Tao about 16 years ago
In build.xml, two new properties were created:
<property name="eml2_0_1-schema-tag" value="RELEASE_EML_2_0_1" />
<property name="eml2_0_1-style-tag" value="RELEASE_EML_2_0_1_UPDATE_6" />
eml201 will be checkout twice to copy schema and style sheets respectively.
The result turned out new installation will get correct eml201 schema and style sheets. It works fine.
Manually copying RELEASE_EML_2_0_1 schema to knb production was postponed. We need to coordinate with bug 3241 - Update older invalidated eml201 document in Metacat.
Updated by Jing Tao almost 16 years ago
following above plan and it is done. I wrote a script to compare schema file and the result shows now they are same to RELEASE_EML_2_0_1.