[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] CIF-2 changes
- To: Nick.Spadaccini@uwa.edu.au, Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] CIF-2 changes
- From: James Hester <jamesrhester@gmail.com>
- Date: Wed, 11 Nov 2009 17:23:10 +1100
- In-Reply-To: <C71F83C7.123CE%nick@csse.uwa.edu.au>
- References: <20091110072125.L55567@epsilon.pair.com><C71F83C7.123CE%nick@csse.uwa.edu.au>
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 -- T +61 (02) 9717 9907 F +61 (02) 9717 3145 M +61 (04) 0249 4148 _______________________________________________ ddlm-group mailing list ddlm-group@iucr.org http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- Follow-Ups:
- Re: [ddlm-group] CIF-2 changes (Nick Spadaccini)
- References:
- Re: [ddlm-group] CIF-2 changes (Herbert J. Bernstein)
- Re: [ddlm-group] CIF-2 changes (Nick Spadaccini)
- Prev by Date: Re: [ddlm-group] UTF-8 versus extended ASCII
- Next by Date: Re: [ddlm-group] CIF-2 changes
- Prev by thread: Re: [ddlm-group] CIF-2 changes
- Next by thread: Re: [ddlm-group] CIF-2 changes
- Index(es):