[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:
>On Sat, Sep 4, 2010 at 1:36 AM, Bollinger, John C
><John.Bollinger at stjude.org> wrote:
>> 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
>> "text".
>
>I have strong doubts that such local defaults are sufficiently robust,
>well-defined, and consistently used to allow us to follow CIF1 in this
>respect.

One of the reasons this disagreement has been so difficult to resolve is that there is no agreed set of goals or priorities for us to rely upon.  Our discussion has ascended to that level once or twice, where it revealed that our divide goes that high.  In this particular case, I don't think we can agree about whether CIF2 can follow CIF1 in this respect without first agreeing on the objectives for CIF2.

>  And, even if such local defaults were reliable, the issue
>would remain of writing portable CIF programs (portable between
>language environments as well as operating systems) and transfer of
>such files between each language environment/operating system.

Those are appropriate considerations for the discussion we should be having, about the objectives for CIF2.  I do want CIF2 to support portable programs (in both the senses you mention).  I want it also to be easy to program for, to the extent that's possible.  On the other hand, although I see the allure of binary uniformity for CIFs, I am not persuaded that that's where CIF2 should go.

I would have additionally preferred full backwards compatibility with CIF1.  That's a lost cause, but there seems to be an idea that CIF2 should nevertheless be backwards-compatible in some approximate sense -- for instance, the draft talks about CIF2 software handling CIF1 syntax.  Requiring UTF-8 for CIF2 is in direct opposition to that objective.  With that as the rule, CIF1's expectation that CIFs comply with local text conventions would in CIF2 become a requirement that CIFs NOT comply with local text conventions on most current systems, unless by accident.  We all know that files conforming to CIF1 would accidentally comply with the proposed CIF2 convention in many important cases, but it would be a mistake to let that obscure the fact that a 180-degree design reversal is being considered.


Regards,

John

--
John C. Bollinger, Ph.D.
Computing and X-Ray Scientist
Department of Structural Biology
St. Jude Children's Research Hospital
John.Bollinger at StJude.org
(901) 595-3166 [office]
www.stjude.org


Email Disclaimer:  www.stjude.org/emaildisclaimer