[Cif2-encoding] How we wrap this up

[SIMON WESTRIP]

Faced with the options:

1. Herbert's 'as for CIF1 proposal with UTF8 in place of ASCII' recently posted 
here and to COMCIFS.
2. Herbert's 'as for CIF1 proposal with UTF8 in place of ASCII', together with 
Brian's *recommendations*
3. UTF8-only as in the original draft
4. UTF8 + UTF16
5. UTF8, UTF16 + "local"

I have to vote for (4).

When it comes down to it, I believe that the specification of a 'standard' 
should not be based on uncertainty,
and as 'any encoding' presents uncertainty, it should not be in the standard.

I might be accused of changing my position (I have recently expressed support 
for flexibilty and even a qualified
acceptance of the 'as for CIF1 proposal with UTF8 in place of ASCII'), but part 
of the value of these discussions
is to question your own views in the light of other's perspectives. Indeed, I 
have found these discussions 

extremely informative and am now in a far better position to handle the 
realities of introducing non-ASCII CIFs,
whatever the final COMCIFS decision.

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: Thursday, 23 September, 2010 15:02:25
Subject: Re: [Cif2-encoding] How we wrap this up

On Thursday, September 23, 2010 5:46 AM, SIMON WESTRIP wrote:

>1. Herbert's 'as for CIF1 proposal with UTF8 in place of ASCII' recently posted 
>here and to COMCIFS.
>2. Herbert's 'as for CIF1 proposal with UTF8 in place of ASCII', together with 
>Brian's *recommendations*
>3. UTF8-only as in the original draft
>4. UTF8 + UTF16
>5. UTF8, UTF16 + "local"
>
>These can be broken down to:
>
>'any encoding' (1, 2, and 5)
>
>'specified encoding' (3 and 4)
>
>Note I put 5 in the 'any encoding' category as I think 'local' could be 
>interpretted as any encoding.

I agree that 'local' could be interpreted as "any encoding", but I choose to 
view it as "context-dependent".  Thus a file that is CIF-conformant on one 
computer might not be CIF-conformant on another.  Some will find that 
unsatisfactory.  In my view, however, it is the best interpretation of CIF1's 
provisions; its purpose is thus to ensure that *all* well-formed CIF1 files are 
also well-formed CIF2 files (a context-dependent question).  Lest I appear to 
overstate the case, I acknowledge that the UTF8-only and UTF-8 + UTF-16 
proposals would have the result that a large majority of well-formed CIF1 files 
are also well-formed CIF2 files.  The variations of Herb’s proposal probably 
also make all well-formed CIF1 files well-formed CIF2 files, but I disfavor them 
on different grounds (mostly that they are too open to differing 
interpretations).

[...]

>In either case, a degree of work will be required to accommodate user practice 
>and the legacy of CIF1.

I think the entire question reduces to which accommodations for the CIF1 legacy 
are assured by CIF2 vs. which will constitute non-standard extensions.  I don’t 
think that individual responses, from Chester for example, are likely to depend 
much on which option is adopted, but I do think the overall consistency of 
responses will be affected.  Thus I favor precision of the specification and 
coverage of the likely uses, in hope of achieving the greatest consistency of 
response.

I doubt this has swayed anyone's opinion, so please consider it an advance 
explanation for my upcoming vote (inasmuch as I rely on James's previous 
assurance that voting rights in this context are not restricted to COMCIFS 
members).


Best 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/20100923/39f5e2e2/attachment-0001.html