[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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?
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@iucr.org
http://scripts.iucr.org/mailman/listinfo/cif2-encoding
Reply to: [list | sender only]
Re: [Cif2-encoding] How we wrap this up
- To: Group for discussing encoding and content validation schemes for CIF2 <cif2-encoding@xxxxxxxx>
- Subject: Re: [Cif2-encoding] How we wrap this up
- From: SIMON WESTRIP <simonwestrip@xxxxxxxxxxxxxx>
- Date: Tue, 28 Sep 2010 12:19:22 -0700 (PDT)
- In-Reply-To: <8F77913624F7524AACD2A92EAF3BFA5416659DEDE7@SJMEMXMBS11.stjude.sjcrh.local>
- References: <AANLkTi=hmKNFMgaeMqt69=sG6dOmxZRUrffB1khjF+mZ@mail.gmail.com><526633.3484.qm@web87004.mail.ird.yahoo.com><alpine.BSF.2.00.1009240742480.8859@epsilon.pair.com><613218.81205.qm@web87011.mail.ird.yahoo.com><281388.90819.qm@web87012.mail.ird.yahoo.com><463665.7127.qm@web87004.mail.ird.yahoo.com><alpine.BSF.2.00.1009251413550.93269@epsilon.pair.com><262880.46378.qm@web87002.mail.ird.yahoo.com><alpine.BSF.2.00.1009251537250.57408@epsilon.pair.com><a06240800c8c5653f38cf@192.168.2.104><476110.27334.qm@web87005.mail.ird.yahoo.com><a06240805c8c6224b8789@192.168.2.104><a06240803c8c65f78a402@149.72.2.199><8F77913624F7524AACD2A92EAF3BFA5416659DEDE3@SJMEMXMBS11.stjude.sjcrh.local><alpine.BSF.2.00.1009271801070.86201@epsilon.pair.com><alpine.BSF.2.00.1009271900080.86201@epsilon.pair.com><AANLkTikudiXBk7orHSAH=JonoeQHeNXVrzvAZmH3Wt94@mail.gmail.com><646265.82162.qm@web87004.mail.ird.yahoo.com><8F77913624F7524AACD2A92EAF3BFA5416659DEDE7@SJMEMXMBS11.stjude.sjcrh.local>
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
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@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?
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@iucr.org
http://scripts.iucr.org/mailman/listinfo/cif2-encoding
_______________________________________________ cif2-encoding mailing list cif2-encoding@iucr.org http://scripts.iucr.org/mailman/listinfo/cif2-encoding
Reply to: [list | sender only]
- Follow-Ups:
- Re: [Cif2-encoding] How we wrap this up (Bollinger, John C)
- References:
- [Cif2-encoding] How we wrap this up (James Hester)
- Re: [Cif2-encoding] How we wrap this up (SIMON WESTRIP)
- Re: [Cif2-encoding] How we wrap this up (Herbert J. Bernstein)
- Re: [Cif2-encoding] How we wrap this up (SIMON WESTRIP)
- Re: [Cif2-encoding] How we wrap this up (SIMON WESTRIP)
- Re: [Cif2-encoding] How we wrap this up (SIMON WESTRIP)
- Re: [Cif2-encoding] How we wrap this up (Herbert J. Bernstein)
- Re: [Cif2-encoding] How we wrap this up (SIMON WESTRIP)
- Re: [Cif2-encoding] How we wrap this up (Herbert J. Bernstein)
- Re: [Cif2-encoding] How we wrap this up (SIMON WESTRIP)
- Re: [Cif2-encoding] How we wrap this up (Bollinger, John C)
- Re: [Cif2-encoding] How we wrap this up (Herbert J. Bernstein)
- Re: [Cif2-encoding] How we wrap this up (Herbert J. Bernstein)
- Re: [Cif2-encoding] How we wrap this up (James Hester)
- Re: [Cif2-encoding] How we wrap this up (SIMON WESTRIP)
- Re: [Cif2-encoding] How we wrap this up (Bollinger, John C)
- Prev by Date: Re: [Cif2-encoding] How we wrap this up
- Next by Date: Re: [Cif2-encoding] How we wrap this up
- Prev by thread: Re: [Cif2-encoding] How we wrap this up
- Next by thread: Re: [Cif2-encoding] How we wrap this up
- Index(es):