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

RE: CIF 2.0 syntax proposal for retaining backwards CIF 1.xcompatibility. .


On Sunday, September 15, 2013 9:59 PM, James Hester wrote:
>
>Reply to Saulius's suggestions of altered syntax.
>===================================
[...]
>incompatibility with CIF1 is not, in itself, news and is not
>sufficient to justify changes to a syntax that has been sweated over
>for many years.
[...]
>It is to avoid such contortions that we agreed to allow
>incompatibility between CIF1 and CIF2.
>
>We need to avoid any further major syntax changes in CIF2. Closing
>the book on syntax changes results in a precise understanding of
>the differences between CIF1 and CIF2, so we can meaningfully explore
>managing CIF1-CIF2 transitions in alternative ways, e.g. through
>documentation and policy.


The fundamental question Saulius raises is whether a new, backwards-incompatible version of CIF is relevant or desirable.  Are the costs of dropping backwards compatibility too high for the benefits we hope to gain?  From a higher perspective, those costs may include some or all of the following:

- Loss of developer good will
- Lack of community acceptance
- Technical issues at various levels arising from confusing one format with the other
- User confusion

As James observed, COMCIFS and the DDLm-WG's position has been that those potential  costs and any others are indeed worth the benefits, so the threshold issue here is whether Saulius has given us sufficient reason to revisit *that* judgment.  I take James's and Herbert's responses to Saulius's proposal as "no" answers to that question.  Myself, I am undecided, though any way around I am not eager to reopen the syntax for changes.

Supposing that we proceed with backward-incompatible CIF 2, as appears to be the momentum, perhaps we should consider ways to reduce the above costs / risks.  One of the main approaches that occur to me is to take all reasonable steps to position CIF 2 as an improved *alternative* to CIF 1 (as James describes it to be), as opposed to an advancement of it.  This would be mostly a promotion and labeling effort.  Steps along that path might include
- relabeling the "Changes" document and the language therein to replace "changes" with "differences",
- making sure to promote CIF 2 as an alternative rather than an evolutionary development when we talk about it with colleagues and in publications,
- emphasizing that CIF1 and CIF2 are expected to coexist for an indeterminate time, and
- promoting a different filename convention for CIF 2 files, such as extension ".cif2" instead of plain ".cif".

Does it make sense to do something like that?


John

--
John C. Bollinger, Ph.D.
Computing and X-Ray Scientist
Department of Structural Biology
St. Jude Children's Research Hospital


Email Disclaimer:  www.stjude.org/emaildisclaimer
Consultation Disclaimer:  www.stjude.org/consultationdisclaimer
_______________________________________________
comcifs mailing list
comcifs@iucr.org
http://mailman.iucr.org/mailman/listinfo/comcifs

Reply to: [list | sender only]