Discussion List Archives

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

Re: [ddlm-group] CIF-2 changes


Obviously I will argue Option 1: as I have from the beginning. I am willing
to give up this option once I know

(a) There is an expectation that we have to support existing CIF1 names and
(b) the mm and sm communities aren't willing to drop [ ] and / from data
names in CIF2. (Many of them have been deprecated from the sm dictionary)

Otherwise I (begrudgingly) vote Option 2:

Except I would choose a more explicit function name like getValue() or use a
MySQL-ish approach like

_atom_site.aniso_U = [`_atom_site.aniso_U[1][1]`,...]

This might be do-able. The back tick (`) initiates the parser into a context
of spanning the contents as a string, and getting the value of the
aniso_U[1][1] from the _atom_site object. Used on the left hand side of a
statement it would be setting the value.

This is all predicated on ` is excluded as an allowed character in the data
name. Now go on - tell me there already is a data name with a ` included -
make my day!

I am increasingly coming to the conclusion that we need to exclude as many
characters outside of [A-Za-z0-9_.] as possible from data names :)

On 11/11/09 2:23 PM, "James Hester" <jamesrhester@gmail.com> wrote:

> Following is a short analysis of the dREL/brackets situation.
> 
> Problem: If datanames contain characters that are syntactically
> meaningful in dREL, it will impossible to refer to those datanames in
> dREL methods.  For example, in order to build up a nice matrix out of
> the individual _atom_site.aniso_U[i][j] items now present in mmCIF, a
> dREL method would have to refer to them, e.g.
> 
> _atom_site.aniso_U = [[_atom_site.aniso_U[1][1],...]
> 
> but the [1] will be wrongly interpreted as an array reference.
> 
> ======================
> Options for a solution:
> 
> Option 1: Ban all dREL syntactically meaningful characters from CIF2
> datanames, handle CIF1 square brackets in custom conversion software
> if DDLm is needed
> 
> Option 2: Add a built-in dREL function to 'quote' the contents.  If
> this function is called 'dataname', then the above line becomes:
> 
> _atom_site.aniso_U = [dataname("_atom_site.aniso_U[1][1]"),...]
> 
> This function need only be used where the syntax does not permit
> straighforward use of the name.
> 
> Option 3: Allow brackets in datanames, but create an additional
> dataname in the relevant dictionary which is an exact alias to the
> problem dataname for use in dREL methods.  So in the above example, we
> might add a dataname to the dictionary called '_atom_site.aniso_U_11',
> and state that it is an alias for _atom_site.aniso_U[1][1].  dREL code
> would follow the alias to get the value for aniso_U[1][1]
> 
> ============
> 
> I view option 2 as the elegant solution.  It is analogous to the
> Python 'getattr' function.  That is, in Python the syntax xxx.yyy
> refers to the yyy attribute of object xxx, but if the string 'yyy'
> contains characters that are meaningful to Python (like square
> brackets) you can't use the xxx.yyy syntax directly.  Instead, you can
> call the built-in 'getattr' function like so: getattr(xxx,"yyy").
> 
> Regardless of what we decide in the concrete case of brackets, such a
> function should in any case be included in dREL to make it more robust for
> integration into other contexts.
> 
> Regarding the other options, Option 1 assumes a coupling between DDLm
> and dREL, rather than viewing them (at least in a formal sense) as
> independent systems.  Option 3 uses the DDLm system to work around
> what I would call a deficiency in dREL, and produces extra dataitems
> in order to do this.  Given that it is not too late to improve dREL, I
> would prefer to fix it rather than mess with the CIF2 syntax or DDL
> dictionaries

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

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.

Useful links