[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: "Herbert J. Bernstein" <yaya@pair.com>
• Date: Thu, 19 Sep 1996 07:45:22 -0400 (EDT)

Please pardon me if this point was made earlier in the discussion.  I am
new to this list and have not yet found the archive of older messages.

The needs to handle images and other binary data structures extend to
many areas of crystallography, not least into the need to handle
images for publication.  If possible, it would be very desirable to
use the work being done on image CIF to suggest a framework for the
handling of general data within all CIF's.  This would, at first seem
to be at odds with the need for high efficiency in the image CIF
application, but I think there is a possible approach to combine
both the general ascii CIF requirement and the need for efficient
binary representations.

Could we not agree that for any computer language, there are both
external interchange formats and more efficient internal formats.
We could have everything that has been suggested and preserve a
clean ascii interchange format for CIFs by many approaches.  Here is
one:

   1.  Right now the image CIF approach is for an ascii header
followed by binary data.  Let us move the possibility of alternation
between ascii and binary down to the data value level, i.e., that
the type definition of _any_ tag in a CIF could allow for a binary
data value (e.g. equivalent to association of a MIME type).

  2.  For appropriate data items, there could be alternate presentations
of the same information in mutually exclusive forms (similar to the
mutual exclusion used for B's and U's).  Some of the alternate forms
could well be internal binary forms which, for formal archiving and
general interchange purposes, should be mapped to some ascii equivalent.
(this does not mean that parties could not exchange binary files, just
that for presentation to an arbitrary stranger, one would have the
capability of giving him a well-defined ascii version).

  3.  When embedding one of these broadly typed fields into a CIF,
they would start and end just like a text field (i.e. with \n;) and
the only restriction on the handling of the data within the field
would be appropriate escaping or counting to protect embedded \n;
data.

Other than giving image CIF the capability of carrying multiple
binary data items in one overall data block, this need change very
little in the format proposed, and general CIF applications gain
a new tool.
  -- H. J. Bernstein

Reply to: [list | sender only]

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