Discussion List Archives

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

Re: CIF or NOT CIF, (or nothing)

  • To: Multiple recipients of list <imgcif-l@bnl.gov>
  • Subject: Re: CIF or NOT CIF, (or nothing)
  • From: Peter Keller <bsspak@bath.ac.uk>
  • Date: Mon, 18 Dec 1995 06:48:30 -0500 (EST)
Hi all,

Since it was partly my comments about encoding that started some of the
current debate, I think that I'd better clarify a couple of points. 

> >   1: CIF based, using encoding to convert binary data to ASCII
> 
> Let me be straight. There is no future in any ASCII encoding, for the image 
> itself. ASCII encoding does not add any advantage for archives and makes the 
> files much bigger. 
> 
> What is the inconvenient in binary encoding of the data?
> 
> - Transferability? 
> Today ftp exists everywhere and allows binary transfer. The lengthy battle 
> between ASCII and EBCDIC and limitations in transfer is over.

There is no problem with having either binary or ASCII data. The 
'objection' to binary data, is that it is incompatible with at least some 
of the aims of CIF. That, however, is not strictly a technical problem.

The problems start when people start talking about mixing ASCII and binary
in the same file, without specifying exactly what 'text' data is. In
general, the nature of text data is system dependent, and there is no
transfer utility, as far as I know, which will switch between text and
binary modes part way through a file. 

>From the Unix perspective, mixing text and binary data is easy enough, as
happens with the MIFF format, but that is not true of all systems. It is
dangerous, in my opinion, to assume that just because Unix-type file
structures (or lack of them) are very common now, that they will remain a
de-facto standard for all time. Just think about what has happened in the
last 20 years.... 

It is always possible, of course, to say "By text, we mean
variable-length, line-feed delimited records, which only contain
characters from the ASCII character set", but this kind of approach
jeapordises the readability of text data using general tools (such as the
text editor(s) supplied with some system or other). 

> >   2: CIF based "header file", using file pointers to point to binary file(s)
> 
> This is the wise solution. There is no reason to encode the header with 
> something different from ASCII. 
> 
> For our purpose we have established our own format. In the first version the 
> header was binary encoded. It is now ASCII.
> 
> This allows to read the header without any conversion, with any utility 
> (including a text editor) and will make the link to a database software easier.

I agree completely that this is the best way forward, with the proviso
that the standard must define some restricted rules for filenames and
pathname components, and/or some meta-syntax for pathnames.

> >   4: Break with existing CIF to at least some extent, probably because a
> >      file contains binary data. This could be "CIF" sections within a binary
> >      files, or could be any other non-CIF format.
> 
> Please explain the difference with 2.

As I understand it, this involves mixing of text and binary data within
files. I find it difficult to believe that this kind of solution is
future-proof, unless someone undertakes to maintain a toolbox for every
current and future system. 

Merry Christmas to you all,
Peter.

========================================================================
Peter Keller.            \ "The self-respect which other men enjoy
Dept. of Biology and      \  in rising early I feel due to me for
    Biochemistry,          \  waking up at all."
University of Bath,         \ 
Bath, BA2 7AY, UK.           \        --- William Gerhardie
------------------------------\-----------------------------------------
Tel. (+44/0)1225 826826 x 4302 | Email: P.A.Keller@bath.ac.uk (Internet)
Fax. (+44/0)1225 826449        |   P.A.Keller%bath.ac.uk@UKACRL (BITNET)
========================================================================


Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.