[eml-dev] [Bug 1132] - fix access control rule ambiguities

[bugzilla-daemon at ecoinformatics.org]

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=1132





------- Comment #9 from mob at icess.ucsb.edu  2008-08-28 16:51 -------
Created an attachment (id=189)
 --> (http://bugzilla.ecoinformatics.org/attachment.cgi?id=189&action=view)
schema illustration

Text of a recent message on eml-dev, also here. This is a model that Chris and
I came up with recently, for simplifying the access tree in EML.

In this model, the <access> tree appears only at the top level, and no longer
under dataset, citation, software and protocol.  The AccessRuleType now has a
0..many child, <describes>, for holding the id of the node that the rule
applies to. If the <describes> is absent, then the rule applies to the whole
document. An instance would look like this:

 <eml>
   <access authSystem="knb" order="allowFirst">
     <allow>
       <describes>table.1.1</describes>
       <principal ... >
       <permission ...>
     </allow>
     <deny>
       <describes>table.2.1</describes>
       <principal ... >
       <permission ...>
     </deny>
  </access>
  <dataset>
           ...dataset markup...
  </dataset>
</eml>

We should encourage use of the order attribute (should it be required?) so that
authors will be fully aware of the the rules  they create. Rules should be
applied in the order they appear (after what is dictated by the order
attribute). Presumably, if no order attribute is included, then the rules are
applied as they appear.  Keeping the access tree in one area at the top of the
document makes maintenance simpler, and the <describes> element acts as it does
under <additionalMetadata>.

It would have to be decided if access rules should still be allowed in
<additionalMetadata>.  These could be 1) not recognized as EML access trees
since node-level control can be described in eml/access, or 2) discouraged for
the same reason, but applied, or 3) allowed and applied after the eml/access
rules.

The model itself doesn't catch conflicting access rules, but it does simplify
descriptions, making it easier for authors to see potential hang-ups. One way
to control some basic conflicts might be to embed a rule-based schema, like
Schematron. Conflict detection could also be added to the eml-parser.

Since the access tree is only available at the <eml> level, then this would end
the use of dataset, citation, etc as root level elements for some purposes (e.g
metacat) -- since metacat's default behavior is to allow access only to the
logged-in owner if no access tree is present. In order to specify that a doc
was publicly-readable, an author would have to wrap the dataset in
<eml>...</eml> to include those access instructions.

Access is a major issue, and it would be good to get some discussion going.
Here, we've only addressed simplifying the location of the access tree, it's
another whole issue to deal with conflicts. It's always been slated for 2.1,
but we may need to discuss that, too.

thanks -
Margaret and Chris