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

RE: _atom_site_aniso_label is broken

• Subject: RE: _atom_site_aniso_label is broken
• From: "Bollinger, John Clayton" <jobollin@xxxxxxxxxxx>
• Date: Mon, 20 Jun 2005 11:31:06 -0500

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

Reply to: [list | sender only]

• Follow-Ups:
  • RE: _atom_site_aniso_label is broken (Nick Spadaccini)
  • RE: _atom_site_aniso_label is broken (Herbert J. Bernstein)

• 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):
  • Date
  • Thread