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

Re: File identifier (was Re: Seattle Discussions)

• To: Multiple recipients of list <imgcif-l@bnl.gov>
• Subject: Re: File identifier (was Re: Seattle Discussions)
• From: "I. David Brown" <idbrown@mcmail.CIS.McMaster.CA>
• Date: Thu, 19 Sep 1996 10:22:18 -0400 (EDT)

	Peter has asked for clarification on a couple of points.

	I am not sure how willing COMCIFS will be to reserve data_cbf_. 
However, this dataname only has significance when it is inside a 
cbf.  Once it is there, cif rules no longer apply.  I suppose the danger 
is that a genuine cif with no binary attanchement might by chance start with 
		data_cbf_r3x
which would confuse any cbf software that tried to read it into thinking
that it was reading a cbf compliant binary file.  Would this be a
disaster?  Presumably the software would read the header succesfully, but
would find no information about the nonexistent binary file that it
expected to follow.  No doubt the program would be puzzled, but it would
probably exit elegently with a message such as 'No binary file found'. 

	I can see no problem with an empty dataset.  However, the cbf 
software would presumably strip out the 'data_end' item before writing the 
rest of the header as a cif.  'data_end' would be part of the cbf 
definition but not part of cif.

			David


*****************************************************
Dr.I.D.Brown
Brockhouse Institute for Materials Research, 
McMaster University, Hamilton, Ontario, Canada
1-(905)-525-9140 ext 24710
*****************************************************

Reply to: [list | sender only]

• Prev by Date: Re: File identifier (was Re: Seattle Discussions)
• Next by Date: Re: area detector cif definitions
• Prev by thread: Re: File identifier (was Re: Seattle Discussions)
• Next by thread: Seattle Discussions
• Index(es):
  • Date
  • Thread