It is case insensitive and my recollection of discussions is different to
that David's. Case sensitivity becomes important in dREL because the data
name is an identifier that we translate immediately in to code. Most
languages are case sensitive.
What we discussed was retaining case insensitivity in the data file so that
one could have _atom_site_frac_x or _Atom_Site_Frac_x and still mean the
same thing. What was proposed or discussed was that within dREL the data
names only appear as lower case, and that at an application level as one
stored the data name it would dataname.toLower() first so that we were
consistent.
That is a solution and one we use in our system. Since it is case
insensitive we choose a particular case to be consistent internally. You
choose toUpper if you want it doesn't matter, sol long as you trap the fact
that _atom_site_frac_x and _Atom_Site_Frac_x are the same.
I think it is particularly problematic to now introduce case sensitivity,
having everybody use to it. And if you "transition" in to a case sensitivity
how will you know if the file submitted today is one that is case sensitive
or insensitive.
I think leave it as case insensitive (not the values just the tags).
On 12/01/10 1:11 AM, "Joe Krahn" <krahn@niehs.nih.gov> wrote:
> If the consensus is lower-case data names, why not make this part of the
> CIF2 standard?
>
> My suggestion is that every data name should have a "printed form"
> defined in the dictionary. That allows upper-case, spaces, subscripts,
> etc. Then, the item name "I_over_sigmaI" can be written as something
> like "I / sigma(I)". Maybe some already do this?
>
> With UTF-8 support, names can include non-ASCII characters, such as
> Greek letters. If non-ASCII characters are used, it might be good to
> have a plain ASCII alias rather than assume that UTF-8 is ubiquitous.
>
> Joe
>
>
> David Brown wrote:
>> There was discussion about case sensitivity of data names at the COMCIFS
>> meeting in Osaka. My recollection is that we agreed that names should
>> be case sensitive, and to avoid problems with having two data names that
>> differ only in their cases, all data names should be lower case. There
>> are legacy problems because in DDL1 the data names are case insensitive,
>> and while most of the names have been written in lower case, upper case
>> letters have been traditionally used for proper names, e.g.,
>> _space_group_name_Hall. There may well be legacy CIFs in which only
>> lower case letters have been used but probably not many.
>>
>> DAvid
>>
>> Joe Krahn wrote:
>>> Is there any interest in making CIF2 case-sensitive, at least data names?
>>>
>>> There was some discussion that names may eventually extend into the UTF
>>> range, even though it would be avoided for the near future. That
>>> complicates case-insensitive matching, because standard library
>>> functions are locale dependent. If data names are not strictly limited
>>> to 7-bit ASCII, it would be good to make names case-sensitive.
>>>
>>> Thanks,
>>> Joe Krahn
>>> _______________________________________________
>>> ddlm-group mailing list
>>> ddlm-group@iucr.org
>>> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>>
>>
>
> _______________________________________________
> ddlm-group mailing list
> ddlm-group@iucr.org
> http://scripts.iucr.org/mailman/listinfo/ddlm-group
cheers
Nick
--------------------------------
Associate Professor N. Spadaccini, PhD
School of Computer Science & Software Engineering
The University of Western Australia t: +61 (0)8 6488 3452
35 Stirling Highway f: +61 (0)8 6488 1089
CRAWLEY, Perth, WA 6009 AUSTRALIA w3: www.csse.uwa.edu.au/~nick
MBDP M002
CRICOS Provider Code: 00126G
e: Nick.Spadaccini@uwa.edu.au
_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group

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.