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

Draft and analysis of proposed change to DDL1.4 to fix_atom_site_aniso_label

• Subject: Draft and analysis of proposed change to DDL1.4 to fix_atom_site_aniso_label
• From: James Hester <jrh@xxxxxxxxxxxx>
• Date: Wed, 22 Jun 2005 17:22:02 +0900

I've taken the liberty of putting together the following draft proposal,
simplifying the text of the change and analysing the result.  I've had
to mess with the wording, and alter two DDL definitions instead of one,
in order to make case 5 below invalid.  Essentially parents and children
are equal in terms of _list_mandatory, but _list_reference can only be
resolved by adding child data names to the looped dataname list, not the
other way around.

I checked the other official DDL1 dictionaries, and this change indeed
is only relevant to atom_site in cif_core. 

James
------------------------
Motivation
==========

The only way of constructing a valid CIF block with the current
cif_core.dic and DDL1 spec requires that all items in the atom_site
category are listed in a single loop, and this loop must include *both*
_atom_site_label and _atom_site_aniso_label.  This arises because both
of these data names are specified as _list_mandatory in cif_core.dic. 

The original intention was to enable anisotropic data to be presented
either in a separate loop or together with the other atom_site data.

This situation arises only for the atom_site category in cif_core.dic.
No other official DDL1 dictionaries specify more than one
_list_mandatory data name per category.

Draft of proposed change to DDL1.4 
==================================

(1) The following is added to the _definition attribute of the
_list_link_child definition block in the DDL1.4 spec:

"When the _list_link_child data name is of the same category as the
defined data name, the _list_link_child data name may be considered to
be present in any loop containing the defined item for the purpose of
resolving _list_reference and _list_mandatory requirements."

(2) The following is added to the _definition attribute of the
_list_link_parent definition block:

"When the _list_link_parent data name is of the same category as the
defined data name, the _list_link_parent data name may be considered to
be present in any loop containing the defined item for the purpose of
resolving _list_mandatory requirements."

Analysis
========

Case 1:  atom_site data in single loop, no atom_site_aniso_ data names,
both _atom_site_aniso_label and _atom_site_label present

Currently: Valid
With new spec: Valid


Case 2: atom_site data in single loop with or without aniso data,
_atom_site_label present, _atom_site_aniso_label missing.

Currently: Invalid (_atom_site_aniso_label is _list_mandatory)
With new spec: Valid (_atom_site_aniso_label can be interpreted as being
present by part (1) for both _list_mandatory and _list_reference)


Case 3: atom_site data in single loop with or without aniso data, only
_atom_site_aniso_label present

Currently: Invalid (_atom_site_label is mandatory; _list_reference from 
           non-aniso data items can't be resolved; _list_link_parent must 
           exist in block)
With new spec: Invalid (_list_link_parent must exist; _list_reference
from non-aniso data items to _atom_site_label cannot be resolved)


Case 4: atom_site data and atom_site_aniso_ data in separate loops with
_atom_site_label and _atom_site_aniso_label respectively

Currently: Invalid (both labels are _list_mandatory so must both appear
in all loops in the atom_site category)
With new spec: Valid (_list_mandatory satisfied by para (1) and (2);
_list_reference satisfied even without new behaviour)


Case 5: As for case 4, with the label items swapped between loops

Currently: Invalid as for case 4
With new spec: Invalid (_list_reference can't be satisfied for non-aniso
items as _list_reference can only be resolved by addition of child to
data name list)
_______________________________________________
cif-developers mailing list
cif-developers@iucr.org
http://scripts.iucr.org/mailman/listinfo/cif-developers

Reply to: [list | sender only]

• Follow-Ups:
  • Re: Draft and analysis of proposed change to DDL1.4 tofix _atom_site_aniso_label (David Brown)

• Prev by Date: spilt lists in DDL 1.4
• Next by Date: Re: spilt lists in DDL 1.4
• Prev by thread: Re: Tidying up DDL1 (last time?)
• Next by thread: Re: Draft and analysis of proposed change to DDL1.4 tofix _atom_site_aniso_label
• Index(es):
  • Date
  • Thread