[Cif2-encoding] How we wrap this up

[SIMON WESTRIP]

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.

Cheers

Simon




________________________________
From: "Bollinger, John C" <John.Bollinger at STJUDE.ORG>
To: Group for discussing encoding and content validation schemes for CIF2 
<cif2-encoding at 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?


Regards,

John
--
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 at iucr.org
http://scripts.iucr.org/mailman/listinfo/cif2-encoding
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://scripts.iucr.org/pipermail/cif2-encoding/attachments/20100928/691f5970/attachment-0001.html