RE: _atom_site_aniso_label is broken

["Herbert J. Bernstein" <yaya@xxxxxxxxxxxxxxxxxxxxxxx>]

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