For the record, I observe that although the parser will flag an error if the key of a table entry is bare or is a text block instead of being a quoted string, its recovery path from such errors will accept those keys. In the case of bare keys, the key is interpreted to end at the first colon, if there is one, or else at whitespace if it precedes the colon.
Supposing that we do not intend to reopen discussion on what form keys may take, I intend this merely as a heads-up that (1) it would be feasible from a language design perspective for a future revision of the language to allow those forms, and (2) users of the API will have a route (involving discarding parse errors) to successfully parse variant documents that are well-formed CIF 2.0 except for use of table keys of these forms.
Forum for CIF developers to define an application programming interface for CIF software.
1 post • Page 1 of 1