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

Re: [ddlm-group] CIF header

• To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
• Subject: Re: [ddlm-group] CIF header
• From: James Hester <jamesrhester@gmail.com>
• Date: Wed, 28 Oct 2009 10:02:39 +1100
• In-Reply-To: <4AE70F95.5000702@niehs.nih.gov>
• References: <4AE70F95.5000702@niehs.nih.gov>

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



-- 
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group

Reply to: [list | sender only]

• Follow-Ups:
  • Re: [ddlm-group] CIF header (David Brown)
  • Re: [ddlm-group] CIF header (Herbert J. Bernstein)

• References:
  • [ddlm-group] CIF header (Joe Krahn)

• Prev by Date: [ddlm-group] testers for cifget version 1.1
• Next by Date: Re: [ddlm-group] CIF header
• Prev by thread: [ddlm-group] CIF header
• Next by thread: Re: [ddlm-group] CIF header
• Index(es):
  • Date
  • Thread