EML

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

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?

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

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.

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.

We should add otherEntity/method to this group:

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
eml/dataset/otherEntity/method

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

Original Bugzilla ID was 3508