Project

General

Profile

Story #4188

dataone Exception definition and implementation requires clarification

Added by Dave Vieglais over 10 years ago. Updated about 6 years ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
d1_schemas
Target version:
Start date:
2013-11-27
Due date:
% Done:

30%

Story Points:
Sprint:

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

Task #4189: Update dataoneErrors.xsd to match the documentationIn ProgressDave Vieglais

Task #4190: Update architecture docs to import dataoneErrors.xsdNewDave Vieglais

Task #4191: Update python implementations of DataONE exceptionsClosedRoger Dahl

Task #4192: Notify MN implementations of the discrepancy in exception definitionIn ProgressDave Vieglais


Related issues

Related to Infrastructure - Bug #7967: The CN is not following the xml schema definition when creating dataone exceptions In Progress 2017-01-14

History

#1 Updated by Dave Vieglais over 10 years ago

  • Status changed from New to In Progress

#2 Updated by Dave Vieglais about 10 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 about 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 over 9 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 about 7 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 about 7 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 about 7 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 about 6 years ago

  • Sprint set to CCI-2.3.8

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 14.8 MB)