search

NCEAS / eml

Ecological Metadata Language (EML)
https://eml.ecoinformatics.org/
GNU General Public License v2.0
41 stars 15 forks source link

create a stylesheet for EML2.0.x to EML 2.1.0 #216

Open mbjones opened 7 years ago

mbjones commented 7 years ago

Author Name: Margaret O'Brien (Margaret O'Brien) Original Redmine Issue: 3508, https://projects.ecoinformatics.org/ecoinfo/issues/3508 Original Date: 2008-10-06 Original Assignee: Matt Jones

there are 4 changes in EML 2.1.0 which need to be addressed in a transformation stylesheet. Summarized:

  1. datetime -> dateTime (bug #1152)
  2. new additionalMetadata/metadata element (bug #2054)
  3. method -> methods (bug #2568)
  4. access trees moved (bug #1132)

Detailed:

  1. xpath in instance docs: /eml/dataset/dataTable/attributeList/attribute/measurementScale/datetime becomes .../dateTime

  2. xpath in instance docs ( neq ): /eml/additionalMetadata/ becomes /eml/additionalMetadata/metadata/*

  3. method was declared in entity group, so all these paths become "methods": eml/dataset/dataTable/method eml/dataset/spatialRaster/method eml/dataset/spatialReference/method eml/dataset/spatialVector/method eml/dataset/view/method eml/dataset/storedProcedure/method

  4. access trees moved: case 1: access tree at resource level: /eml/dataset/access and /eml/software/access moved to eml/access

case 2: access tree(s) in additionalMetadata sections: Current behavior: Do not recognize siblings of additionalMetadata/describes that reference /eml/dataset/distribution /eml/software/distribution

Recognize siblings of additionalMetadata/describes that reference /eml/dataset/dataTable/physical/distribution /eml/software/implementation/distribution

recognizable cases: 4.2.1.one additionalMetadata/describes element pointing a recognized node, with one sibling access tree action: move the access tree, remove additionalMetadata section

4.2.2. two (or more) additionalMetadata/describes elements pointing to recognized nodes, with one sibling access tree action: copy the access tree to both locations, remove additionalMetadata

4.2.3 two (or more) additonalMetadata/describes 4.2.3.1 references a distribution node action: remove the , copy the access tree to the referenced node 4.2.3.2 references some other non-recognized node action: leave the , additionalMetadata/access -> additionalMetadata/metadata/access

4.3. one additionalMetadata/describes element pointing to a recognized node, with multiple sibling access trees (in eml 2.0.x, these will need to have been wrapped in another element in order to be valid) action: move nothing. can't deal with elements that arent 2.0.1 [aside: addtionalMetadata section will have tag added per item 2. above ]

4.4 the eml-author created access trees in additionalMetadata that contain non-eml material. we cannot move these to other parts of the EML instance document. [aside: If metacat has encountered additional not-eml elements alongside access elements, it would have ignored them.]

To be sure output is valid EML, a script should include the parser to check the doc against the schema. Can the stylesheet do this alone? Jing and margaret not sure.

4.1. assuming stylesheet finds the non-eml material (ie, it can parse), possible actions include: a? ignore access tree, but wrap it in or b? reject document, tell use that the resulting eml will be invalid or c? rebuild access tree in the new location (ie, try to interpret what author wanted)

mbjones commented 7 years ago

Original Redmine Comment Author Name: Margaret O'Brien (Margaret O'Brien) Original Date: 2008-10-07T18:46:08Z

Regarding dateTime: the path for this template can be shortened to attributeList/attribute/measurementScale/datetime

since attributeList appears in these schemas eml-dataTable.xsd eml-entity.xsd eml-spatialRaster.xsd eml-spatialVector.xsd eml-storedProcedure.xsd eml-view.xsd

mbjones commented 7 years ago

Original Redmine Comment Author Name: Jing Tao (Jing Tao) Original Date: 2008-10-07T22:32:44Z

The access subtree for data file level can be:

/eml/software/implementation/distribution /eml/dataset/dataTable/physical/distribution /eml/dataset/spatialRaster/physical/distribution /eml/dataset/spatialVector/physical/distribution /eml/dataset/view/physical/distribution /eml/dataset/otherEntity/physical/distribution /eml/dataset/storedProcesure/physical/distribution

We propose to use two paths: //physical/distribution //software/implementation/distribution

do you see any problem?

mbjones commented 7 years ago

Original Redmine Comment Author Name: Margaret O'Brien (Margaret O'Brien) Original Date: 2008-10-15T21:46:16Z

This is another case for how access trees could have been used in eml201 case 4.3

/dataset/access and /dataset/distribution with an id attribute and additionalMetadata fpresumably for overriding document-level access for this node.

?? Mike says that metacat recognizes these nodes on eml201 docs. But in EML210, there is no access tree available to resource-level distribution elements (only at entity-level). So the question is what to do with this case. Options: a. ignore it (and lose access control at this level) b. create an entity, and move the distribution tree to it, and copy the access tree from additonalMetadata as well

mbjones commented 7 years ago

Original Redmine Comment Author Name: Jing Tao (Jing Tao) Original Date: 2008-10-15T22:15:09Z

I guess the access control on resource-level should be a mistake. EML 2.0.1, we should only have two level - document level and entity level. This is reason why eml 2.1.0 only has the two levels.

mbjones commented 7 years ago

Original Redmine Comment Author Name: Margaret O'Brien (Margaret O'Brien) Original Date: 2008-10-15T23:56:04Z

regarding case 4.2 (from irc) daigle that is the case that we use in all the test cases for 2.0.1 inline access daigle bunches of tests daigle in fact, that's the only case that I'm positive works :)

So metacat does recognize /dataset/distribution nodes. But there is a variant of this case that we cannot transform to 2.1.0. If the doc also has access rules in additionalMetadata that override the /dataset/distribution with another access tree, then there is no place to move that second access tree.

There might be the possiblity of this action: create an otherEntity, with a distribution tree, and copy the access tree from additonalMetadata to there. This would also require adding a otherEntity/physical/distribution/references node which referred to dataset/distribution (who's id attribute would have to be generated if it didn't exist). All this is possible (although is it advisable?) But the deal breaker is this: the entity group has some other required elements whose content we know nothing about. So I think this sub-case falls into the category of those docs we cannot transform.

In the eml/test directory, see the doc eml-datasetWithAccessOverride.xml, also attached to this comment. This test is similar to the doc we would be trying to create.

mbjones commented 7 years ago

Original Redmine Comment Author Name: Jing Tao (Jing Tao) Original Date: 2008-10-21T17:56:47Z

We should add otherEntity/method to this group:

  1. method was declared in entity group, so all these paths become "methods": eml/dataset/dataTable/method eml/dataset/spatialRaster/method eml/dataset/spatialReference/method eml/dataset/spatialVector/method eml/dataset/view/method eml/dataset/storedProcedure/method eml/dataset/otherEntity/method
mbjones commented 7 years ago

Original Redmine Comment Author Name: Margaret O'Brien (Margaret O'Brien) Original Date: 2009-04-02T17:36:21Z

Open stylesheet bugs are now associated with EML's Utility component

mbjones commented 7 years ago

Original Redmine Comment Author Name: Redmine Admin (Redmine Admin) Original Date: 2013-03-27T21:23:39Z

Original Bugzilla ID was 3508