Open ion-oset opened 2 years ago
Heck yes.
Cliff and I had a schema for this a while back, where there was a human readable that was usually but not guaranteed to be unique with an EDF, appended with an ordinal to be unique.
As I recall contests were like contest-mayor, candidates were like candidate-spacely-contest-mayor and candidate-writein-1-contest-spaceport-board; and question-helium-initiative etc. The ballot section IDs would be directly derived from them like selection-candidate-spacely-contest-mayor and selection-question-helium-initiative-yes
In a later phase I want a generation tools to follow some rubric roughly like this, but for now, the yucky IDs are what we've got to work with on a tight schedule.
@trustthevote to be clear: this ticket isn't tied to the current milestones, and we're not trying to solve this before the tight schedule is done. It's here so we can track on it going forward, and because it's come up in BallotLab debugging.
Fwiw we're going to be collecting ideas for that scheme/algorithm at the discussion I linked in the top post.
@cwulfman I've realized there's potentially two different issues here.
Do you think it makes sense to split 2 into a separate ticket or is it good enough as it is?
It is much easier to verify and debug EDFs if the
@id
s are human readable and describe the element and context they are in. For the current test cases we don't need a perfect scheme just a reasonably well-defined one.Discussion of the details will be ongoing at Human-readable identifiers in NIST documents.