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

Re: [ddlm-group] CIF header

Title: Re: [ddlm-group] CIF header
The fact that # can be parsed as a comment is the reason for using it. Look for it in the first line, or if you don’t you pass straight over it as if it were a comment (which it is).


On 28/10/09 9:38 PM, "David Brown" <idbrown@mcmaster.ca> wrote:

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).

David


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
out.

Are we all agreed on having a mandatory header?

On Wed, Oct 28, 2009 at 2:19 AM, Joe Krahn <krahn@niehs.nih.gov> <mailto: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
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group

 




  




_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group

cheers

Nick

--------------------------------
Associate Professor N. Spadaccini, PhD
School of Computer Science & Software Engineering

The University of Western Australia    t: +61 (0)8 6488 3452
35 Stirling Highway                    f: +61 (0)8 6488 1089
CRAWLEY, Perth,  WA  6009 AUSTRALIA   w3: www.csse.uwa.edu.au/~nick
MBDP  M002

CRICOS Provider Code: 00126G

e: Nick.Spadaccini@uwa.edu.au


_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group

Reply to: [list | sender only]