[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: _atom_site_aniso_label is broken
- Subject: Re: _atom_site_aniso_label is broken
- From: Nick Spadaccini <nick@xxxxxxxxxxxxx>
- Date: Mon, 20 Jun 2005 10:21:21 +0800 (WST)
- In-Reply-To: <1118998435.18478.173.camel@anbf10>
- References: <1118992457.18478.123.camel@anbf10><Pine.LNX.4.62.0506171602410.8371@mostaccioli.csse.uwa.edu.au><1118998435.18478.173.camel@anbf10>
On Fri, 17 Jun 2005, James Hester wrote: > In my ideal world, you could work straight off the published specs for > DDL1.4 to interpret the cif_core dictionary - am I asking too much?. > There is *absolutely nothing* in the _list_link_child and > _list_link_parent DDL1.4 entries to indicate any semantics other than > that the child can only take values that the parent takes (although you > did suggest how this could be enhanced, in, what, 1993?). And > _atom_site_aniso does not exist as a category in cif_core 2.3. Even in what you say above there must be "implied" semantics (or pragmatics). To require the keys must have the same values is meaningless without the implication you can do a JOIN. Almost all of the operational aspects of DDL1.4 was implied - you will recall at the time the term in response to specific questions was universally "that would be application dependent". STAR/CIF/DDL1.4 were essentially container framework detailing a syntax and a loose structure. What you did with its content was up to you given a you included a limited set of "implied" semantics for the DDL. > So, to present Brian with his choices as I see them... > > (1) a transparent fix in the spirit of DDL1.4 which makes current > behaviour valid (use _list_reference instead of _list_mandatory) I don't recall the details of DDL1.4 so the meaning of _list_reference is hidden in the depths of (my failing) memory. I wouldn't be surprised if your perceived fix had some other side-effect. > (2) a perhaps more controversial fix: create an _atom_site_aniso > category - this breaks previous cifs where everything was looped > together, but they are technically broken already. No it wouldn't break them. The semantics of this structure in StarDDL is that you can execute a JOIN on split loops in different (parent-child) categories or it can be stored in that form (think of it as a pre-JOIN, with you being able to execute a SPLIT, if you so wanted). > (3) a single line fix: use _related_function 'alternate' - not sure if > this is really in the spirit of DDL1. Not sure what this would do either. Brian is the expert on the DDL1.4 meanings - enlighten us oh bearded one. > What have other validating CIF programmers done in this case?? <tongue in="cheek"> Which other CIF programmers? </tongue> cheers Nick -------------------------------- Dr N. Spadaccini, Head of School School of Computer Science & Software Engineering The University of Western Australia 35 Stirling Highway CRAWLEY, Perth, WA 6009 AUSTRALIA CRICOS Provider Code: 00126G voice: +(61 8) 6488 3452 fax: +(61 8) 6488 1089 w3: www.csse.uwa.edu.au/~nick email: head@csse.uwa.edu.au (Mail to "head" is for official correspondence and is accessible to several others, in particular my Administration Officer/PA). email: nick@csse.uwa.edu.au (Mail to "nick" is for confidential, personal and trivial correspondence, and is accessible only to me). _______________________________________________ cif-developers mailing list cif-developers@iucr.org http://scripts.iucr.org/mailman/listinfo/cif-developers
Reply to: [list | sender only]
- Follow-Ups:
- Re: _atom_site_aniso_label is broken (James Hester)
- References:
- _atom_site_aniso_label is broken (James Hester)
- Re: _atom_site_aniso_label is broken (Nick Spadaccini)
- Re: _atom_site_aniso_label is broken (James Hester)
- Prev by Date: Re: _atom_site_aniso_label is broken
- Next by Date: Re: _atom_site_aniso_label is broken
- Prev by thread: Re: _atom_site_aniso_label is broken
- Next by thread: Re: _atom_site_aniso_label is broken
- Index(es):