Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minimum of contest options in contest definition diferent in CastVoteRecords and ElectionResultsReporting #40

Open
alejandroclaro opened this issue Apr 21, 2023 · 2 comments

Comments

@alejandroclaro
Copy link

alejandroclaro commented Apr 21, 2023

Organization Name: Smartmatic

Organization Type: 2. Industry

Document (e.g., CastVoteRecords): CastVoteRecords

Reference (Include section and paragraph number): pag. 29 table row 3

Comment (Include rationale for comment):

There appears to be an inconsistency in the definition of the contest compared to the NIST 1500-100 document. In the contention definition in 1500-103 the minimum number of contest options is one (1), however in 1500-100 it is zero (0). It should be possible to keep the same contest definitions in both reports and to be able to define contest without options.

This is also specified in this way in the schema definitions (e.g. XSD).

Suggested Change: Change the minimum of contest options to zero (0).

Reference from ElectionResultsReporting:
image

and the diference in CastVoteRecords:
image

@JDziurlaj
Copy link
Collaborator

I have confirmed that this difference exists between ERRv2 and CVRv1. Were you planning to associate CVRContest with this "empty" Contest, i.e. connect them via ContestId?

@alejandroclaro
Copy link
Author

alejandroclaro commented Oct 4, 2023

Hi @JDziurlaj

Sorry for some time without looking again at this.

About your question. Not that we are forced to any use case that needs to associate the CRVContest with an empty Contest. However, there are multiple ways to represent some cases, but assumptions need to be present. For example, in the CRVContest

image

There are no strong requirements on how to use the elements. So, the CVRContest could have only the Contest reference. This could be the case for to represent abstention in a contest, but also could be that the reason for not having voter selections is that there are no selection to be made (an "empty" contest); and for example, this could be accompanied by the use of ContestStatus to further explain the situation.

Now, That is not the reason I reported the issue. The problem we saw is that it is possible to use ERR to define the definition of the elections, such as reporting results. In the other hand, the CVR report has also the definition of the election or part of it. However, because of this inconsistency, the definitions can not be the same between the two when there are contests without contest options (contest selections).

We could simply not include it (the contest) in the CVR report, but we could also include a contest selection without code and perhaps other workarounds. It is not clear what the correct form should be, and in the end it seems inconsistent with the ERR when the system has support to both.

It looks like the only reason for the inconsistency is a discrepancy in the multiplicity in the documents.

From my point of view, I still think that the solution is to fix the inconsistency in these structures that are very similar, conceptually the same, and respond to related use cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants