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

Re: [ddlm-group] CIF header

Agreed. -- Herbert

  Herbert J. Bernstein, Professor of Computer Science
    Dowling College, Kramer Science Center, KSC 121
         Idle Hour Blvd, Oakdale, NY, 11769


On Wed, 28 Oct 2009, 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> 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
ddlm-group mailing list

Reply to: [list | sender only]