CIF formal specification
Brian McMahon bm at iucr.orgThu Mar 3 20:05:48 GMT 2005
- Next message: CIF formal specification
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
While working through final proofs of the Volume G chapter on the CIF specification, I have taken the opportunity to address two minor problems. (1) John Bollinger wrote to me to say: > I was going over the specifications for CIF 1.1 currently available from > IUCr at http://www.iucr.org/iucr-top/cif/spec/version1.1/cifsyntax.html, > and I found a minor inconsistency related to use of the string > "global_". Paragraphs 11, 33, and 57 seem to say that only the string > "global_" itself is forbidden as an unquoted data value, whereas > paragraph 55 says that string is forbidden as the _start_ of an unquoted > data value. Which is correct? global_ in STAR does not take a label, and so its behaviour should be the same as loop_ and stop_ (rather than data_ and save_, both of which may be expanded with a label). While all these constructs are classified as reserved words, the difference in handling the complete and partial words is made explicit in para 57 of the syntax document. I have therefore changed paragraph (55) to read 55. The reserved word global_ (in a case insensitive form). This is actually a reserved word of STAR, but is defined here so that it may be explicitly excluded as an unquoted string. This is done so that any possible future adoption of STAR features will not invalidate existing CIFs. instead of 55. The reserved word global_ (in a case insensitive form). This is actually a reserved word of STAR, but is defined here so that it may be explicitly excluded as THE START OF an unquoted string. This is done so that any possible future adoption of STAR features will not invalidate existing CIFs. (2) Peter Murray-Rust told me that the formal specs do not actually state explicitly that the order of data names is irrelevant. I have addressed this by adding the text in capitals to para (7): 7. A given data name (tag) (see 2.4 and 2.7) may appear no more than once in a given data block or save frame. THERE IS NO SIGNIFICANCE TO THE ORDERING OF DATA NAMES WITHIN A DATA BLOCK OR SAVE FRAME. THAT IS, A DATA NAME WITH ITS ASSOCIATED DATA VALUE OR SET OF DATA VALUES MAY BE RELOCATED WITHIN THE SAME DATA BLOCK OR SAVE FRAME WITHOUT CHANGING THE INTERPRETATION OF THE DATA. A tag may be followed by a single value, or a list of one or more tags may be marked by the preceding reserved case-insensitive word loop_ as the headings of the columns of a table of values. White space is used to separate a data block or save frame header from the contents of the data block or save frame, and to separate tags, values and the reserved word loop_ If there are no objections, these changes will be incorporated in Volume G. Regards Brian _________________________________________________________________________ Brian McMahon tel: +44 1244 342878 Research and Development Officer fax: +44 1244 314888 International Union of Crystallography e-mail: bm at iucr.org 5 Abbey Square, Chester CH1 2HU, England bm at iucr.ac.uk
- Next message: CIF formal specification
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the comcifs mailing list