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

[bugzilla-daemon at ecoinformatics.org]

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





------- Comment #10 from jones at nceas.ucsb.edu  2008-08-28 18:06 -------
This solution, although nicely consolidated, fails to address the major problem
that originally caused us such trouble and triggered the access control changes
in the first place.  Basically, the use of references to define access
restrictions on arbitrary subtrees creates massive complexity when trying to
figure out how people that have partial read and partial write capabilities on
a document could succeed in modifying a document.  I don't think using
references to arbitrary subtrees is a viable solution, for the same reasons
outlined at the start of this bug report.  So, I still think the best solution
is the one we proposed earlier in this thread:

<eml>
  ...
  <access>...</access>           <-- defines overall access to 
                                     all metadata
  ...
  <dataset>
    <dataTable>
      <physical>
        <distribution>
          <access>...</access>   <-- defines access to the data object
                                     in inline, online, or offline 
                                     elements (ie, not the metadata 
                                     itself, just the data)
          <inline>...</inline>
        </distribution>
      </physical>
    </dataTable>
  </dataset>
</eml>

This uses a top-level eml/access element for defining access to the whole
metadata document, and it allows entity-specific access blocks in the
distribution element for specifying rules for handling specific data entities. 
This does not allow access constraints on arbitrary subtrees, and therefore is
tractable from an implementation perspective.  Plus, it is really just setting
separate ACLs for the metadata and data files, which is manageable in our
current access table because each of these has its own docid.

Note that any access blocks in additionalMetadata would now be ignored, plus
there is no longer an access element as a child of the eml-dataset module (or
any other eml-resource extensions) because these rules are specified at a
higher level in the /eml/access element.

This approach represents an incompatible schema change from EML 2.0.1 that
would require document conversion to create valid instance of 2.1.0, but I
think it is worth it given the gains in simplicity and clarity.