Bug #3313

Edit EML documentation for access control

Added by Callie Bowdish almost 13 years ago. Updated over 12 years ago.

eml - general bugs
Target version:
Start date:
Due date:
% Done:


Estimated time:


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

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."


#1 Updated by Margaret O'Brien over 12 years ago

Documentation should describe the intended use of access trees in 2.1.0 at these locations:

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.

#2 Updated by Margaret O'Brien over 12 years ago

edited component that bug refers to

#3 Updated by Margaret O'Brien over 12 years ago

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

#4 Updated by Margaret O'Brien over 12 years ago

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."

#5 Updated by Matt Jones over 12 years ago

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:

&lt;xs:restriction base="xs:string"&gt;
&lt;xs:enumeration value="read"/&gt;
&lt;xs:enumeration value="write"/&gt;
&lt;xs:enumeration value="changePermission"/&gt;
&lt;xs:enumeration value="all"/&gt;
&lt;xs:restriction base="xs:string"/&gt;

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.

#6 Updated by Margaret O'Brien over 12 years ago

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

#7 Updated by Redmine Admin about 8 years ago

Original Bugzilla ID was 3313

Also available in: Atom PDF