usnistgov / VoterRecordsInterchange

Common data format specification for voter records interchange data
https://pages.nist.gov/VoterRecordsInterchange
Other
14 stars 2 forks source link

Error Handling in VriRecordsResponse #8

Closed JDziurlaj closed 6 years ago

JDziurlaj commented 6 years ago

Right now the subtype of VriRecordsResponse, RequestRejectionhas three attributes: AdditionalDetails, Error, and OtherError. Since all these errors are at the same "level", it is very difficult to contextualize errors that are specific to a certain part of the request payload. For example, assume that there is a requirement that the voter's party must be be defined. Right now the response would need to look something like this:

<n2:VoterRecordsResponse xmlns:n2="NIST_V0_voter_records_interchange.xsd">
    <n2:Error>other</n2:Error>
    <n2:OtherError>party-missing</n2:OtherError>
</n2:VoterRecordsResponse>

What you end up with is a lot of duplicative error codes with the difference between them being the target of the error rather than the kind.

Proposed Changes

  1. Add an attribute called Ref that would serve as a pointer to the target node(s). The pointer language used would be dependent on the transmission format used (e.g. XPath for XML, JSON Pointer for JSON).
  2. Move attribute from (1), Error and OtherError to a composed class Error off of RequestRejection (see image below).

image

Then we would end up expressing the earlier example as such:

<n2:VoterRecordsResponse>
    <n2:Error>
        <n2:Name>other</n2:Name>
        <n2:OtherError>missing-required-field</n2:OtherError>
        <n2:Ref>/VoterRecordsRequest/Subject/Party</n2:Ref>
    </n2:Error>
</n2:VoterRecordsResponse>

Remove the following enumeration literals from RequestError

Perhaps, some new, more general RequestError enumeration values could be developed as well.