Bug #3313
closed
Edit EML documentation for access control
Added by Callie Bowdish almost 16 years ago.
Updated over 15 years ago.
Category:
eml - general bugs
Description
The ability to restrict access is a common request. I think it would be good to add the following information regarding how to restrict access to a dataTable. I think this is the most common request.
The description at this location http://knb.ecoinformatics.org/software/eml/eml-2.0.1/index.html#N100A8
would be more helpful with the following addition.
---
An example for restricting a dataTable but not the metadata about the dataTable would require editing a specific distribution element. It is nested inside these elelments: <dataTable><physical><distribution><distribution/></physical></dataTable>. There will be other elements nested inside the dataTable element but the distribution element inside the physical element which is inside the dataTable element is the one that needs to be referenced by its ID. The ID needs to be added to the distribution element. <distribution id="999999">. The id needs to be a unique number within the eml file.
----
I think it would be good to add the text in the section two part of the second paragraph, after "... element by referencing its unique id."
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
Also available in: Atom
PDF