-
Notifications
You must be signed in to change notification settings - Fork 1
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
Meta Data Dictionary for ABIF #14
Comments
I think this issue may be a sub-issue to issue #15 that I just filed. In particular, one thing that I'm curious about: should it be possible to express the metadata for an ABIF file as unordered key-value pairs, or does order matter? |
A counter-question: do you see any use-case for having order-sensitive metadata in ABIF? |
I don't see any reason order would matter. If for example we decide that the type ie 'rcv' and the option 'allow_equal' should be different keys, if the parser reads all the metadata into key value before checking it, the order in the file will not matter. We can specify that the metadata can be in any order, for readability recommend that related keys be grouped and ordered from most significant to least significant if possible. For a one pass parser to work, metadata needs to be before ballots. Most programming languages key/value data type randomizes the keys so the key order in the file should be of no consequence. |
Part of the discussion in #6 has been about what might be included in metadata, consensus there looks like it will be an optional but probably important part of the format. An issue raised is the NIST CVR vote record format. The purpose of the metadata dictionary would be to establish the key names and data types for the metadata, and also to cover mapping values from CVR and possibly other formats. The discussion in #6 is quite lengthy and the dictionary will require considerable discussion on its own.
The text was updated successfully, but these errors were encountered: