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

Re: [ddlm-group] options/text vs binary/end-of-line. .. .. .. .... .. .. .. .. .. .. .. .. .


On Thursday, July 15, 2010 8:04 PM, SIMON WESTRIP wrote:
>>"...Scheme B provides for reliable exchange and archiving; it is not intended to be an integral part of the CIF format..."
>
>However worthy such schemes may be, if they are not to be "part of the CIF format" (whatever it may turn out to be) perhaps
>discussion of such here overly complicates/confuses the matter?

Perhaps so, but it's the question James asked:

>1. How do we then make exchanging and storing files according to text conventions sufficiently reliable for the
>purposes of CIF?  How far are we prepared to compromise?

The question of whether reliability features are baked into the CIF format or whether they are an aspect of CIF handling is roughly equivalent to the question of whether CIF2 should be a binary format or a text format.  Making features such as hashing a mandatory part of the CIF format would mean that CIFs could be correctly created or modified only by CIF-aware tools, hence CIF2 would be a true binary format (as opposed to the text-ish binary format that so far has been carrying the flag on that side).

> I note the desire to pursue this elsewhere and am in favour of exploring methods of exchange and archiving (indeed I'm resisting the temptation/distraction to follow-up on some of these ideas, e.g. I like the idea of 'zipping a CIF' with all related data files, with dictionary-defined links to the related data); however, inevitably a CIF will have to be a CIF, whether it be 'text' with a declared encoding or 'binary' with unambiguous byte order, or ...

James, too, expressed some concern about the existence of CIF-like files that are not genuine CIFs, but that is an inevitable outcome of every possible binary-CIF option.  CIF content is defined in textual terms, so there will always be uses for storing CIF text in files (or database columns, etc.) conforming to text conventions.  All possible binary-CIF options make at least some of these formally non-CIF.  Therefore, the only way I see for simply "a CIF [...] to be a CIF" is to embrace and accommodate CIF as a text format.  To put it another way, it is the CIF *text* that is fundamentally "a CIF"; anything else is just packaging.


Regards,

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


Email Disclaimer:  www.stjude.org/emaildisclaimer
_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group

Reply to: [list | sender only]