EML

Documentation should describe the intended use of access trees in 2.1.0 at these locations:
eml/access
eml/dataTable/.../physical/.../access

And tell users that node-level access control is problematic to implement. Therefore, access trees in additionalMetadata sections (which referenced any node in previous versions) will probably be ignored by applications like metacat.

edited component that bug refers to

these bugs are for stylesheet and documentation updates. changed to EML.2.1.0 priority 3, to be taken care of after changes to schema

this is done, except for one part describing the permission element. when this is confirmed OK or cleaned up, then this bug can be closed.

This sentence: "...This element also allows other permission values that may be applicable to some other authentication systems but are not defined in this specification (if these other values are used, access rule enforcement is indeterminate outside of the originating system)."

This element specifically does not allow any other values, since it is a xs:enumeration list. Should this statement instead be a caveat about the fact that EML has no idea how some other authSystem works, or might treat the same value? as in something like:
"These permission values may have other meanings in the referenced authentication system, however rule enforcement is indeterminate outside of the originating system."

I think the current description is accurate and should not be changed. The 'permission' field is typed as union of the defined permission types plus xs:string, as follows:

<xs:simpleType>
          <xs:union>
            <xs:simpleType>
              <xs:restriction base="xs:string">
                <xs:enumeration value="read"/>
                <xs:enumeration value="write"/>
                <xs:enumeration value="changePermission"/>
                <xs:enumeration value="all"/>
              </xs:restriction>
            </xs:simpleType>
            <xs:simpleType>
              <xs:restriction base="xs:string"/>
            </xs:simpleType>
          </xs:union>
        </xs:simpleType>

This allowed us to define the four standard permission types (read, write, changePermission, all) while not ruling out the use of other permission types by specific systems. If people do use other permission values than those defined, the system behavior is undefined in the EML spec. So I think the paragraph is correct.

whoops - missed the union. OK, this one is done.

Original Bugzilla ID was 3313