[Cif2-encoding] [ddlm-group] options/text vs binary/end-of-line . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .

[Bollinger, John C]

On Tuesday, September 07, 2010 12:03 AM, James Hester wrote:
>CIF1 put these text conversion issues into the "somebody else's
>problem" basket (e.g. let Chester figure out what to do with an
>EBCDIC-encoded CIF), which perhaps was efficient and responsible when
>the only contenders were "ASCII-compatible" and "almost-extinct
>EBCDIC".

For what it's worth, I see a decent possibility that UTF-16 will become a non-negligible, non-ASCII-compatible contender in that arena within the next ten years, if it isn't already.  It offers considerable space savings relative to UTF-8 for many non-Latin scripts.

In any case, I disagree that CIF1 relegated text conversion to "somebody else's problem."  Correctly exchanging text between dissimilar systems is *always* a joint problem of sender and receiver.  As a service to the community, Chester shouldered the bulk of that burden for CIF1-conformant submissions, but that was their strategic decision, not something imposed on them by the standard.

Chester will need to make a similar decision regarding CIF2, quite independently of what the standard ultimately says about text encoding.  Either way, my recommendation would be that they accept only UTF-8, and perhaps something like scheme B.  No formulation of the standard that allows those could obligate Chester to accept more.  That pushes the responsibility back to the CIF submitter, where any Unicode-based form of CIF2 I can imagine requires it to be.

In no way do I see any inefficiency or irresponsibility on the part of the CIF2 standardization effort should we ultimately agree that CIF2 encodings will not be limited to UTF-8.


Regards,

John
--
John C. Bollinger, Ph.D.
Department of Structural Biology
St. Jude Children's Research Hospital




Email Disclaimer:  www.stjude.org/emaildisclaimer