Bare table keys

Post a reply


This question is a means of preventing automated form submissions by spambots.
Smilies
:D :) ;) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :!: :?: :idea: :arrow: :| :mrgreen: :geek: :ugeek:

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: Bare table keys

Bare table keys

by jcbollinger » Thu Oct 03, 2013 4:21 pm

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.

Top