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

proposed revisions

• To: imgcif-l@bnl.gov
• Subject: proposed revisions
• From: "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
• Date: Tue, 7 Jul 1998 15:17:07 -0400

As we agreed at the workshop last year, I have been working on adding ascii
hooks to Paul Ellis's API.  Paul did a very nice job of setting up the API
for "binary strings" which makes binary CBF files map quite directly to
MIME-encoded, true ASCII CIFs.  Doing this would require some changes to
John Westbrook's proposed cbfext dictionary.  You can find a proposed
revised draft of the dictionary to accommodate binary strings in a CBF and
MIME-encoded binary strings in an imgCIF at:

   http://www.bernstein-plus-sons.com/software/CBF/xcbfext97.html

The major changes are as follows:

     +  Added binary type, which is a text field containing a variant on
      MIME encoded data.

This means that there would be a new data type which is a variant of a text
field, i.e. a field which begins and ends with "\n;".  Before somebody
notices that you can't have binary data in a CIF, please note that in an
imgCIF this would be the type for  the _ascii_ representation (whence the
MIME encoding) of the binary data you would see in a CBF, just as "1.43e5"
is a perfectly nice example of a "float" data type giving a character
string which actually represents a rather messy binary bit pattern.

   +  Changed type of _array_data.data to binary and specified internal
      structure of raw binary data.

The internal structure is just the layout given by Paul's API, adjusted a
little to use normal MIME boundary flags, and to allow for MIME headers.

   +  Added _array_data.binary_id, and made
      _diffrn_frame_data.binary_id and _array_intensities.binary_id
      into pointers to this item.

This is a minor technical issue.  Originally, the binary ID was supposed to
provide the link between the information in a CBF ascii header and
particular chunks of data in the binary section.  With binary strings, this
is not strictly necessary, since we could just make distinct array.id's and
keep track of which chunk of binary data was which positionally.  However,
John did some nice work on diffrn_frame_data, with a binary ID there, to
keep track of which frame was which.  My suggestion is to combine the
original concept with John's, and allow  _any_ block of array_data binary
information to be identified by an additional binary ID, if desired.  So I
promoted the binary_id into array_data, and made the one in dffrn_frame
into a pointer.  Just for the sake of completeness, I added a similar
pointer in array_intensities, to allow for sets
of intensity parameters to vary with each chunk of data, if desired.

I know this does not make make much sense without examples and a lot more
documentation.  I'm working on it (i.e. more complete and accurate examples
in the dictionary and revisions of Andy Hammersley's and Paul Ellis's
documentation), but thought the dictionary mavens might like to take pot
shots at this while I'm working on the rest.

  Have fun.

  -- Herbert


=====================================================
****                BERNSTEIN + SONS
*   *       INFORMATION SYSTEMS CONSULTANTS
****     P.O. BOX 177, BELLPORT, NY 11713-0177
*   * ***
**** *            Herbert J. Bernstein
  *   ***     yaya@bernstein-plus-sons.com
 ***     *
  *   *** 1-516-286-1339    FAX: 1-516-286-1999
=====================================================

Reply to: [list | sender only]

• Prev by Date: ACA meeting
• Next by Date: proposed revised CBF definition
• Prev by thread: proposed revised CBF definition
• Next by thread: ACA meeting
• Index(es):
  • Date
  • Thread