Discussion List Archives

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

Re: [ddlm-group] CIF header

I agree that a header is needed.  I am concerned about starting it with a # which could still get lost, though I can find no good example of where it would cause a problem.  However, as a matter of principle I think it bad form to have a convention (# = comment) that applies everywhere except in this one location.  Almost any other character would do but this might upset CIF1 parsers.  I suppose the real advantage of starting with # is that it would be ignored by a legacy CIF1 parser without causing a problem (though the parser might have problems later).


James Hester wrote:
I believe that Joe's suggestion of mandating a CIF2.0 header comment
coincides with Brian's earlier suggestion that this should now be
mandatory.  We should also note David's comment that we must now be
careful about stating that comments can be discarded from files, as
the first line comment may be a special case.

Regarding David's comment, I think that we can proceed by stating that
any program that writes a CIF must put in the mandatory CIF2.0 (or
whatever it turns out to be) comment in the header.  This would
include programs that simply strip comments and then write something

Are we all agreed on having a mandatory header?

On Wed, Oct 28, 2009 at 2:19 AM, Joe Krahn <krahn@niehs.nih.gov> wrote:
IMHO, there should be some sort of header to distinguish CIF variants,
sort of like the DOCTYPE line at the top of XML files. This will help
deal with CIF1 files that are not CIF2 compliant, and could also better
handle more extreme variants, like binary CIF. The current syntax
suggests, but does not require, an initial comment line starting with #CIF.

I proposed to the COMCIFS list that global_ could be used for this
purpose. In this way, global_ would only be read by the parser, and not
be considered as part of the actual CIF data. The idea is to use the
existing STAR syntax instead of designing something new. The
disadvantage is that the global_ section itself would have to maintain a
restricted 7-bit ASCII format, and not allow any of the newer STAR/CIF
syntax. So, the "simplicity" of just using the existing STAR syntax
really is not there.

Alternatively, the initial CIF comment line could be made a requirement
rather than a suggestion, and also define a way to include additional
file attributes in the form of param=value pairs. For example, a CIF2
file could add "binary=true" to indicate the presence of binary
sections, rather than binary-CIF having to be a completely separate format.

If extra file attributes seem like an unnecessary complication, then
maybe at least the simple comment line could be made a requirement?
Then, you can distinguish CIF2 files, and assume that any file without a
comment is CIF1.

Joe Krahn
ddlm-group mailing list


fn:I.David Brown
org:McMaster University;Brockhouse Institute for Materials Research
adr:;;King St. W;Hamilton;Ontario;L8S 4M1;Canada
title:Professor Emeritus
tel;work:+905 525 9140 x 24710
tel;fax:+905 521 2773

ddlm-group mailing list

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.