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

Re: [Cif2-encoding] [ddlm-group] options/text vsbinary/end-of-line . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .

James: I am not ignoring our ongoing blockbuster exchange, but I have
been unable to devote the time to it that it deserves.  In the mean
time, I have a shorter response to these comments:

On Thursday, September 02, 2010 11:22 PM, James Hester wrote:
>I agree that CIF1 is not *defined* as ASCII-only, and I have no wish
>to push for any redefinition.  I am stating that CIF1 is used by the
>community *as if* it were ASCII-only.

I think it's more accurate to say that CIF1 is used by the community
under the assumption that CIFs comply with the default text conventions
for the environment.  This is reasonable, because the CIF1 design
assumes that exchange of CIFs between dissimilar environments
involves conversion from one set of text conventions to another (sounds
familiar?).  For example, CIF1 processors are not required to recognize
non-native line termination semantics.

CIF1's limited character repertoire and the great prevalence of
ASCII-compatible character encodings make it tempting to describe that
situation as de facto ASCII-only.  That is a mischaracterization,
however, ignoring CIF1's assumption of text conversion accompanying CIF
exchange.  That assumption makes a great difference if you want to
design CIF software that is reasonably portable to systems that do not
default to an ASCII-compatible encoding.

> When speculating about the
>community response to CIF2, the actual community response to the CIF1
>standard is a perfectly reasonable starting point.

Indeed, hence the continuing line of argument that users would want to
continue to use CIFs encoded according to local convention, just as they
already do.  The new and disruptive thing here is support for non-native
encodings, which in most places include UTF-8.  I want UTF-8, but it's
not free.

>Are you suggesting that a CIF1 application that accepts only ASCII
>encoding is not standards conformant?

I am amused to see you arguing the other side of the "CIF software must
accept all compliant CIFs" argument now :) .

I don't know about Herb, but I would find that program's behavior
unacceptable if it were running on an EBCDIC-based computer.  The
standard says almost nothing about program behavior, so I could not call
the *program* non-conformant, but it would reject conformant
(EBCDIC-encoded) CIFs that I would expect it to accept.

>  Because all that I am asserting
>is that useful CIF1 programs that support non-ASCII encodings are
>either rare or non-existent, despite being allowed by the standard.  I
>see no hint of non-standards-conforming programs in this description.

I suspect that many CIF1 programs would in fact support a non-ASCII encoding
just fine when used on a system where that encoding is the default.  In
fact, I expect that many of them would fail on ASCII- (or UTF-8-)encoded CIFs
in such an environment.  In other words, I believe that there are many useful
CIF1 programs that support non-ASCII encodings, simply as a result of assuming
default text conventions.  This is the difference between "ASCII-only" and

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

Email Disclaimer:  www.stjude.org/emaildisclaimer

cif2-encoding mailing list

Reply to: [list | sender only]