[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CIF formal specification

  • To: comcifs@iucr.org
  • Subject: CIF formal specification
  • From: Brian McMahon <bm@iucr.org>
  • Date: Thu, 3 Mar 2005 20:05:48 +0000
  • Reply-To: "Discussion list of the IUCr Committee for the Maintenance of the CIF Standard (COMCIFS)" <comcifs@iucr.org>
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@iucr.org
5 Abbey Square, Chester CH1 2HU, England                   bm@iucr.ac.uk
_______________________________________________
comcifs mailing list
comcifs@iucr.org
http://scripts.iucr.org/mailman/listinfo/comcifs

Reply to: [list | sender only]