[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: CIF formal specification
- To: "Discussion list of the IUCr Committee for the Maintenance of the CIFStandard (COMCIFS)" <comcifs@iucr.org>, jwest@rcsb.rutgers.edu
- Subject: Re: CIF formal specification
- From: Sydney Hall <syd@crystal.uwa.edu.au>
- Date: Fri, 4 Mar 2005 09:23:27 +0800
- In-Reply-To: <42277A92.6000905@rcsb.rutgers.edu>
- References: <20050303200548.GC22354@emerald.iucr.org><42277A92.6000905@rcsb.rutgers.edu>
Hi John and other comcifers. >> 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. > > I thought the use of global_ had been deprecated. It has no > correspondence in ddl2 applications and I would prefer to see this > just die a quiet death. global_ has certainly not been deprecated in the STAR file syntax and is unlikely to be; being extremely useful for some applications. I believe the wording of 55. points this out correctly and I support its reservation for future CIF considerations. > >> (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_ > Ordering does have some implications. While the order of categories is > of no importance, data items within categories must be collected > together at one point in each data block. The repetition of a category > section in mmCIF is both a logical and syntax error. I believe that John's comment about ordering refers specifically to data items in a looped list. Clearly in this case data items in a given category MUST be together (though the order within that list should not be relevant) because the category key item(s) CANNOT be replicated in another looped list. A looped list may contain only items of the same category. As far as I am aware there is no ordering constraint on data items that are not in a list... and indeed if there were, I suspect that many of the archived CIFs for Acta, and elsewhere, would be non-compliant! Provided that a CIF parser maps data items in a file back to the relevant dictionary I don't see that the category identity is a problem. Cheers Syd ------ Professor Sydney R. Hall School Biomedical & Chemical Sciences University of Western Australia Crawley, 6009 AUSTRALIA. Ph: +61 (8) 6488 2725 Fx: +61 (8) 6488 1118 "Data data everywhere but not a thought to think!" - Theodore Roszak
Reply to: [list | sender only]
- References:
- CIF formal specification (Brian McMahon)
- Re: CIF formal specification (John Westbrook)
- Prev by Date: Re: CIF formal specification
- Next by Date: Re: CIF formal specification
- Prev by thread: Re: CIF formal specification
- Next by thread: Re: CIF formal specification
- Index(es):