How to handle bare candidate tokens without a mapping when other bare tokens have a mapping?

[simberaj]

Consider this ABIF file

[Joe Biden]: JB
[Donald Trump]: DT

125: JB>DT
113: DT>JB
110: JB>DT>JS

What should the parser do when encountering JS?

[robla]

Interesting test case! I think the ABIF implementation can just assume that "JS" is an unnamed candidate, and have implementation-specific behavior. For some implementations, the parser could emit a warning:

WARNING (line 6, bundle 3): undefined bare token "JS" in ballot bundle "110: JB>DT>JS"

Other implementations could insist on having the candidate names defined at the top of the file. Still others could ignore the fact that JS isn't declared yet, and assume the candidate's name is "JS" in the final report that it emits. From a parser perspective, "JS" is a valid bare token ("[A-Z][a-z]*") so parser implementations should treat "JS" as valid before handing off the parsed line to the rest of the implementation.

[simberaj]

Sounds good to me.