Story #1644: Develop an object format creation policy - DataONE API - DataONE Tasks

Story #1644

Develop an object format creation policy

Added by Chris Jones almost 13 years ago. Updated over 6 years ago.

Status:

New

Priority:

Normal

Assignee:

Category:

Target version:

Start date:

Due date:

% Done:

Story Points:

Sprint:

Infrastructure backlog

Description

The object format list in d1_common_java is thus far an ad hoc list of known object formats needed in the D1 software. Additions will be needed. We need to develop a policy on who will have write access to the realtime version of this list, when the on-disk version will be periodically updated, etc. New object formats need to be vetted, and that process should be put into place. This process should align with the object format creation process with the UDFR group when their registry is operational.

History

#1 Updated by Chris Jones almost 13 years ago

Subject changed from Develop an object format modification policy to Develop an object format creation policy

For the CN implementation of addFormat(), we will use a service level of access control where, instead of setting access to the cached XML document in Metacat (an implementation-specific detail), we'll check access on the method itself for a given subject. The service will have a unique identifier, likely the URI of the POST service like 'cn.dataone.org/formats/fmtid', and the AccessPolicy will be checked for that resource. If the subject is listed as having write access to the given service URI, then the addition of the format will be allowed.

Other details:
- The format list needs to be checked prior addition of the new format to ensure fmtid uniqueness
- For Metacat, the access query needs to use guid instead of docid since there is no docid for the listed URI resource in xml_access.
- Object formats are immutable, and so previously registered formats must not change
- The Slice properties of the object format list need to be updated