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.
Bare table keys
Forum for CIF developers to define an application programming interface for CIF software.
Moderators: Brian McMahon, jcbollinger
-
- Posts: 57
- Joined: Tue Dec 20, 2011 2:41 pm
Return to “CIF Application Programming Interface”
Jump to
- Executive Committee
- ↳ Journals review committee
- ↳ IYCr steering committee
- Commissions
- ↳ Crystallographic Nomenclature
- ↳ Biological Macromolecules
- IUCr journals
- ↳ Journal Editors and Section Editors
- ↳ Acta A Co-editors
- ↳ Validation and publication
- International Tables for Crystallography
- ↳ Volume H: Powder Diffraction
- ↳ Volume H planning
- ↳ Volume B: Reciprocal Space
- ↳ Volume B/C planning
- Standing Committees and Working Groups
- ↳ Diffraction data deposition
- ↳ Consultation on diffraction data deposition
- ↳ Public input on diffraction data deposition
- ↳ Description of Nanomaterials
- ↳ Committee on Data
- ↳ Public input to CommDat
- Crystallographic Information Framework
- ↳ CIF Application Programming Interface
- ↳ CIF dictionary namespace conventions
- ↳ NeXus HDF5 CIF convergence
- ↳ Core CIF review and update
- ↳ CIF2.0
- Sandbox
- ↳ Online dictionary tests
- ↳ Testing
- ↳ test