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

Re: Response to Pflugrath

• To: Multiple recipients of list <imgcif-l@bnl.gov>
• Subject: Re: Response to Pflugrath
• From: "I. David Brown" <idbrown@mcmail.CIS.McMaster.CA>
• Date: Fri, 12 Jan 1996 08:31:43 -0500 (EST)

> 	Jim Pflugrath has given an account of a the kind of file structure
> that he would like to see for images.  It seems a feasible structure but
> it most certainly it is not cif, as indeed he indicates in his final
> comment.  The philosphy that lies behind his proposal is quite different
> from that of cif as outlined below.  While there are good reasons for
> making the image files cif-compliant, this is not essential providing we
> can keep some compatibility between the two systems. 
> 
> 	The incompatibilities arise only for the images themselves. 
> Everyone agrees that the headers could be given in ASCII and could be
> therefore be structured as cifs.  At some point the images are going to be
> interpreted in terms of other crystallographic concepts, and this
> information will normally either be available in a cif, or the results of
> the analysis will be written as a cif.  If such information is also to be
> stored in a non-cif-compliant image file, we should at least ensure that
> the contents of the files can be easily transformed from one format to the
> other. 
> 
> 	The specific places where Jim's proposal is not cif compliant are 
> the following:
> 
> 	1. Cifs are ascii files and will remain ascii files.  There many
> problems created by relaxing this constraint.  This means 
> that it is impossible to embed binary text into a cif.  The only two 
> possibilities for using cif extensions for images are for the image to 
> be encoded in ascii or for the cif to point to binary files that contain 
> the image.  Both these alternatives have serious problems.
> 
> 	2. Cifs are composed of character strings and line feeds.  There 
> is no provision for blocking the contents into multiples of 512 
> characters.  By Jim's admission the purpose of blocking is to assist in 
> reading on VMS systems.  It is cif's philosophy not to tie itself into 
> structures that are designed to meet the requirements of specific 
> systems, systems that may not be around in 10 or 20 years' time.  The same 
> arguments explain why form feeds as proposed by Jim are not part of the cif 
> structure.
> 
> 	3. A key feature of cif is that each keyword is followed by a
> single value.  Multiple values as proposed by Jim are not allowed. 
> However, they can be given using a loop structure, so this is not
> necessarily a serious limitation. 
> 
> 	The question that needs to be decided at this stage is whether it
> is possible to implement the image file within cif.  If it is not, then we
> should address the problem of creating an image file structure that allows
> easy interchange with cif for all fields except the image.  Before any file
> structure can be established for images, it is essential to clarify to
> what extent such a file will be cif-compliant or cif-compatible.  By
> cif-compatible I mean that the concepts contained in each file will be the 
> same so that transcription between the two file types is trivial. 
> 
> 			David Brown
> 
> 			Chair of comcifs
> 
> 
> *****************************************************
> 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: Some suggestions on image data files
• Next by Date: Re: Response to Pflugrath
• Prev by thread: Re: Image Headers in cif.
• Next by thread: Re: Response to Pflugrath
• Index(es):
  • Date
  • Thread