Discussion List Archives

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

Re: CIF line limits

On Thu, 16 Nov 2000, Brian H. Toby wrote:

Let me preface this response with the following. The PDB is trying to get
some CIFs out that are greater than 80 char lines. If this distribution is
being held up, awaiting the results of this discussion list then I think
we should do the following. Though we do not agree where to set a new line
length limit or if at all, we are pretty much in agreement that 80 chars
is too small. I think it would be in the PDBs interest to allow them to
distribute their files and for COMCIFs to guarantee what they finally
decide on will encompass what ever line length the PDB has created. That
way they can get on with their job.  

Now in response to Brian T ....

> I know where Nick is coming from. Yes, FORTRAN is dead and gone... but

Now now Brian, I never said FORTRAN was dead and gone, nor do I wish it to
be - even though John Backus (its author) has long apologised for creating
the "monster that will not die"!

I think Fortran 9X goes some way toward making it more mainstream, however
its IO still is arcane and I still think the strong adherence to the
concept of a record is what is problematic - but that language is
specified by the powers that be and that is the way it is.
> we are still running some of the country's best and most modern neutron
> instruments on VAXes with software written in -- guess what language. We
> are not alone in this. I suspect that at most a third of the world's
> major neutron diffractometers have been upgraded to linux (or downgraded
> to ...). The majority still run on VAXes.

Now VAXes! Those I would have guessed were dead and gone .... I'm wrong
yet again!

> In reality, a longer length CIF record length in would probably have
> little in the way of ramifications, but I mention the above to
> demonstrate that the world of computers as seen by the informatics folks
> may not reflect the range of hardware used by those of us in the
> trenches. Thus, I think it very important to preserve backward
> compatibility. If this means keeping an 80 character limit on data name
> length, I urge those of you with votes to retain this requirement.

This is an interesting interpretation of "backward compatibility", Brian.
Usually this term refers to the ability of updated versions of software to
deal with legacy file structures. Eg the Word2000 application will read a
Word5.0 document. What is suggested by many of us will be "backwards
compatible" by definition, our software will read any existing CIF.

However your suggesting that mechanism be put into the file specification
that makes it possible for legacy software to run with a hacked version of
a new file. This is the same as saying the Word5.0 application should be
able to read a Word2000 document. I guess we all have differing views of
compatibility, backwards or forwards - but I still see what you suggest as
an encouragement to not improve existing software to move with the times.
This is always a danger, as people lock themselves into legacy code and
then increasingly demand the file spec meet their needs, as opposed to the
software meeting the needs of the current spec.

I re-iterate what I said in my previous mail, I support the concept of
elided line termination to signal the parser a line wrap is required. But
its purpose is stylistic, it can be applied to a line of any length (not
necessarily just 80 chars - though it can be used for that purpose) and
should not impose a limit on a data name length. In short all legacy
software will have to be updated to deal with the elided line termination,
I suggest it be simultaneously updated to deal with the "complete" new
file specification, then the question of backwards compatibility is
properly implemented.

Fortran lives, it lives I tell you! (ala the scene from Frankenstein).



Dr Nick Spadaccini
Department of Computer Science              voice: +(61 8) 9380 3452
University of Western Australia               fax: +(61 8) 9380 1089
Nedlands, Perth,  WA  6907                 email: nick@cs.uwa.edu.au
AUSTRALIA                        web: http://www.cs.uwa.edu.au/~nick