Story #4188
dataone Exception definition and implementation requires clarification
30%
Description
The documentation describes the properties and serialization of DataONE exceptions:
http://mule1.dataone.org/ArchitectureDocs-current/apis/Exceptions.html
However, the definition in the schema:
https://repository.dataone.org/software/cicore/tags/D1_SCHEMA_1_1_1/dataoneErrors.xsd
differs, and so presents an inconsistent reference for implementations.
The Java code appears to follow the documentation, however the python implementation uses the schema to generate exception messages, and so follows the schema definition.
The schema and python code need to be updated to reflect the description in the documentation. Also, all implementations of MN and client software need to be informed of the issue and how they may be impacted.
Subtasks
Related issues
History
#1 Updated by Dave Vieglais almost 11 years ago
- Status changed from New to In Progress
#2 Updated by Dave Vieglais almost 11 years ago
- Target version changed from 2013.49-Block.6.3 to 2014.2-Block.1.1
- Due date changed from 2013-12-14 to 2014-01-18
#3 Updated by Chris Jones over 10 years ago
- Target version changed from 2014.2-Block.1.1 to 2014.14-Block.2.3
- Due date changed from 2014-01-18 to 2014-04-12
#4 Updated by Dave Vieglais about 10 years ago
- Due date changed from 2014-04-12 to 2014-09-24
- Target version changed from 2014.14-Block.2.3 to Maintenance Backlog
#5 Updated by Rob Nahf almost 8 years ago
- Subject changed from Exception definition and implementation requires clarification to dataone Exception definition and implementation requires clarification
- Target version changed from Maintenance Backlog to CCI-2.4.0
#6 Updated by Rob Nahf almost 8 years ago
- Related to Bug #7967: The CN is not following the xml schema definition when creating dataone exceptions added
#7 Updated by Rob Nahf almost 8 years ago
I think because the embedded schema file in the documentation (working link: http://jenkins-1.dataone.org/documentation/unstable/API-Documentation-development/apis/Exceptions) used the field 'identifier' instead of 'pid' which is used in the html table to name the field, (yet had the new 'nodeId' field, too) the schema that became the 1.1.0 error schema inadvertently changed the 'pid' field to 'identifier', breaking backwards compatibility.
the 'pid' field is optional, and only used with error responses to cn.resolve, and mn.synchronizationFailed calls.
Metacat's MNodeService.synchronizationFailed implementation does check the pid field. If null, a ServiceFailure is returned to the caller. As far as I could tell, Metacat does not call cn.resolve and attempt to extract the value of the 'pid' field.
Because cn.resolves handles SIDs as of v2, maybe the field 'identifier' is most appropriate name for that field, moving forward. (Or synchronization can populate the 'pid' field, and the 'identifier' field is populated by cn.resolve(), and both fields are defined...)
#8 Updated by Dave Vieglais almost 7 years ago
- Sprint set to CCI-2.3.8
