Discussion List Archives

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

Re: [Cif2-encoding] How we wrap this up

Dear John

My main difficulty with the term 'local' is that its difference from 'any encoding' is possibly too subtle to
find a place in a specification of a standard that is not novel (i.e. CIF2 follows CIF1).
I've used Herbert's actual 'As for CIF1...' description as a basis to build upon
partly because it is modelled on this established standard. Perhaps it might further your cause to
present your proposal more completely, and define "text" and "text file" sufficient to program to.

Certainly, although I think I understand your use of "local", I would like to see it presented as part of
a full specification of CIF encoding so that I might determine more clearly how the concept will be received
by current CIF users/developers.



From: "Bollinger, John C" <John.Bollinger@STJUDE.ORG>
To: Group for discussing encoding and content validation schemes for CIF2 <cif2-encoding@iucr.org>
Sent: Tuesday, 28 September, 2010 17:55:34
Subject: Re: [Cif2-encoding] How we wrap this up

On Tuesday, September 28, 2010 4:54 AM, SIMON WESTRIP wrote:
>So I think the 'As for CIF1...' proposals with this explicit default encoding is certainly
>heading towards a workable compromise. Herbert is unhappy to mandate a particular encoding
>for non-ASCII use, but has agreed to recommend UTF8 and UTF16 in such cases.
>Such recommendations along with a default encoding that should be adopted in the absence of
>any pointers to the contrary could boil down to UTF8/16 + local in all intents and purposes,
>and could boil down to UTF8/16 if you want to use non-ASCII text.

Recommending UTF-8 and / or UTF-16 without mandating support for one or both does not get us where I insist we need to be.  In particular, the point of requiring support for at least one specific encoding applicable to the entire CIF2 character repertoire is to provide a means *wholly within the standard* by which conforming parties can be certain of communicating arbitrary CIF content accurately.  The various Unicode Transformation Formats have additional desirable properties in that regard that we have covered extensively.

If establishing UTF-8 as the default encoding confers a mandate to support it then where indeed is the great distinction between 'As for CIF1...' and UTF-8 (+- UTF-16) + local?  If there is one then it can only be in the definition of "text" on the one hand and "local" on the other, which is to say in the details of support for non-UTF-x encodings.  That is an area where perhaps we could find a consensus, or at least a strong majority opinion.  For that to happen, I require definitions of "text" and "text file" sufficient to program to.  James has asked for the same.  "local" already provides such definitions, intended to cover the cases that CIF1 allows and UTF-8 +- UTF-16 does not.  Are there cases it misses that should be covered?  Are there cases it covers that should be missed?


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
cif2-encoding mailing list

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Council for Science (admitted 1947). Member of CODATA, the ICSU Committee on Data. Member of ICSTI, the International Council for Scientific and Technical Information. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

ICSU Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.