[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: "Herbert J. Bernstein" <yaya@xxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 20 Jun 2005 14:15:10 -0400
- In-Reply-To: <E88024C0BA8052478C717D472F978C1803164DB9@iu-mssg-mbx05.exchange.iu.edu>
- References: <E88024C0BA8052478C717D472F978C1803164DB9@iu-mssg-mbx05.exchange.iu.edu>
May I suggest that, when there is serious concern that the strict rule of one loop per category be adhered to, that DDL2 dictionaries be used. -- Herbert At 11:31 AM -0500 6/20/05, Bollinger, John Clayton wrote: >Nick Spadaccini wrote: > >> On Mon, 20 Jun 2005, James Hester wrote: >> > I state that a (any?) reading of the DDL1.4 spec implies that >> > _atom_site_aniso_label is broken. >> > >> > Nick explains that the parent/child relationship between >> > _atom_site_aniso_label and _atom_site_label means that they can be >> > used as keys to join/split loops even during validation, >> consequently >> > solving the list_mandatory and _list_reference problem. >> >> Operationally whether your validator does any joining or >> splitting is an application level decision. What it must do >> is accept either joined or split lists as valid alternatives >> provided they meet the syntactic and structure requirements. > >Your position, then, is that all the items in a particular category that >appear in lists should be considered to be in a single logical list, >regardless of whether they are in the same physical list? Is this a >practical suggestion, or an interpretation of the DDL? The DDL is >ambiguous on the point, for although it says "[...] there may be more >than one looped list of the same category provided that each loop has >its own independent reference item (see _list_reference)" (_category >definition), it also says "Signals if the defined item must be present >in *the* loop structure containing other items of the designated >_category" (_list_mandatory definition; emphasis mine). Frankly, >although the "one list" position is convenient from a practical >standpoint, I don't think it's the most straightforward reading of the >definitions. > >> As far as I can recall >> CIF/DDL were originally syntactic constructs and semantics >> were argued on the fly. Whether or not they were ever agreed >> on is another matter. However much of CIF/DDL1.4 is simple >> and obvious, but there are the occasional contradictions like > > the "quick fix" > > construction of _atom_site_aniso_label to meet rapidly > > evolving requirements (at the time). > >All the more reason to look critically at the definition. I assert that >it _is_ broken, if only because having attribute list_mandatory means >that it MUST appear among the list data for the atom_site category, even >if there was no anisotropic refinement. I suppose you could argue that >the value can be assumed based on the parent link to _atom_site_label, >but if you waved your arms that fast I'd feel the breeze here. > >Even the validity of splitting the atom_site_aniso_* stuff into a >separate physical list depends on this idea of an implied join unifying >multiple physical lists into one logical one for validation purposes. I >agree that the joins themselves are implied by parent/child >relationships, but as far as I can tell, the best support for >interpreting the DDL in terms of one logical list per category is the >fact that splitting out the aniso stuff into its own list and putting it >in the same list with the other atom_site stuff are both supposed to be >valid. Is it unreasonable to decide instead that the dictionary just >didn't succeed in accomplishing that? How much cruft should CIF be >allowed to acquire simply to make an acknowledged "quick fix" correct? > >-- >John Bollinger >jobollin@indiana.edu >_______________________________________________ >cif-developers mailing list >cif-developers@iucr.org >http://scripts.iucr.org/mailman/listinfo/cif-developers -- ===================================================== Herbert J. Bernstein, Professor of Computer Science Dowling College, Kramer Science Center, KSC 121 Idle Hour Blvd, Oakdale, NY, 11769 Office: +1-631-244-3035 Lab (KSC 020): +1-631-244-3451 yaya@dowling.edu ===================================================== _______________________________________________ cif-developers mailing list cif-developers@iucr.org http://scripts.iucr.org/mailman/listinfo/cif-developers
Reply to: [list | sender only]
- References:
- RE: _atom_site_aniso_label is broken (Bollinger, John Clayton)
- 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):