[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
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]
- Prev by Date: Re: CIF or NOT CIF, (or nothing)
- Next by Date: Re: CIF or NOT CIF, (or nothing)
- Prev by thread: Re: CIF or NOT CIF, (or nothing)
- Next by thread: Re: CIF or NOT CIF, (or nothing)
- Index(es):