Discussion List Archives

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

RE: Treatment of Greek characters in CIF2

  • Subject: RE: Treatment of Greek characters in CIF2
  • From: "Bollinger, John C" <John.Bollinger@xxxxxxxxxx>
  • Date: Thu, 20 Apr 2017 13:42:03 +0000
  • Accept-Language: en-US
  • authentication-results: iucr.org; dkim=none (message not signed)header.d=none;iucr.org; dmarc=none action=none header.from=STJUDE.ORG;
  • DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SJCRH.onmicrosoft.com; s=selector1-stjude-org;h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;bh=jR4jvsVXYySQEUXZy2jqbI03naJrl1l8WoH4oMAZNto=;b=EUls4/5UB4BfVepfQBKP2F63HnjNmrgXwZzqIBy4AncaFrGB9r3yelt6k/Ko7eStOTjL0u8tLOSVSbLJj7wcyT4C9r3WJOw+FertuXXzV9CI/MDSi9xLEO6BgY0nCYTTVaEUOugiZAz5kB0uWfJkr4u15AJ6b57XUVj39KAnkY8=
  • In-Reply-To: <CAM+dB2d5NCbCb1Zc_QS3KkjscDH7Sk9NQVbQxhLn0nPtO6E+zA@mail.gmail.com>
  • References: <CAM+dB2d5NCbCb1Zc_QS3KkjscDH7Sk9NQVbQxhLn0nPtO6E+zA@mail.gmail.com>
  • spamdiagnosticmetadata: NSPM
  • spamdiagnosticoutput: 1:99

On Thursday, April 20, 2017 12:38 AM, James Hester wrote:
> According to section - 17 of International Tables Vol G, by default Greek and some other non-ASCII characters can be represented in text datavalues using a backslash notation <backslash><ascii character>, e.g. \a is alpha.   Different markup conventions are possible on a per-dictionary or per-definition basis. In CIF2, these characters can be represented natively, but legacy CIF applications presented with a datavalue containing non-ASCII values may not be prepared to typeset or present them appropriately.  On the other hand, it would seem inefficient to define separate Unicode-aware datanames for every text value simply to avoid legacy problems.
> I view this as a secondary issue in that very few if any machine-interpretable datavalues rely on the backslash convention (perhaps a few enumerated values for X-ray tube radiation type?).
The problem arises only with CIF2 (obviously). As a starting suggestion, what do you think of the following as a notional additional paragraph for the above-mentioned section
> ( Whenever an application is required to convert a datavalue from a CIF2 datafile containing code points outside the ASCII range to a datavalue containing only ASCII codepoints, the appropriate markup as per paragraphs should be substituted, provided that the relevant definition meets the requirements of paragraph If no markup is defined for the Unicode code point, no CIF1 equivalent value exists and application behaviour is undefined.
> I toyed with the idea of allowing '\Uxxxxxx' for arbitrary Unicode code points, but (i) this would clash with '\U' for capital upsilon and (ii) is not expected by legacy applications and so would therefore require that they be updated, in which case adapting them to just ingest Unicode would be more straightforward.
> Thoughts?

I think that to whatever extent and in whatever context the proposed specifications are natural, they do not require any special more force or support behind them.  On the other hand, where they are _not_ natural, they _should not have_ any force or support behind them.  Consider in particular that ITVG conditions use of the markup codes on permission from the relevant dictionary, therefore any rule that directs conversions to those coded forms without regard to items' definitions is inappropriate.

I'm inclined to say that the best available approach is for software to use (some encoding of) Unicode as the internal representation of CIF data, and to convert that as needed to appropriate external forms, where the relative propriety of different external forms is context-dependent.  CIF 1.1 with traditional CIF markup codes (+/- some convention for general Unicode characters) is a widely-recognized and used external form, so it may often be the best choice, but that's no justification for asserting that it should be the only choice, especially given its well-known limitations.

I acknowledge that it poses a clear risk of data corruption and/or misinterpretation if different external forms cannot easily be distinguished from each other, but I don't think that's a problem that we can reasonably hope to solve by fiat.



Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer
_______________________________________________cif-developers mailing listcif-developers@iucr.orghttp://mailman.iucr.org/cgi-bin/mailman/listinfo/cif-developers

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

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

International Science Council 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.