[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] CIF-2 changes
- To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] CIF-2 changes
- From: Nick Spadaccini <nick@csse.uwa.edu.au>
- Date: Wed, 11 Nov 2009 15:04:09 +0800
- Authentication-Results: postfix;
- In-Reply-To: <279aad2a0911102223r2d05cb93v4f96929b295777ec@mail.gmail.com>
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]
- References:
- Re: [ddlm-group] CIF-2 changes (James Hester)
- Prev by Date: Re: [ddlm-group] CIF-2 changes
- 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):