Re: Tidying up DDL1 (last time?)

[James Hester <jrh@xxxxxxxxxxxx>]

Some more nitty-gritty issues relating to the DDL1 spec.

1.  _type_construct for _enumeration_range and _dictionary_update
make use of the embedded match expressions "_sequence_minimum",
"_sequence_maximum", "_chronology_year" etc.  These are nowhere
defined, so you can forget machine readability.  How about just
putting in standard POSIX match expressions from the DDL2 dictionary?
Furthermore, the present _type_construct spec says
 
(_sequence_minimum):((_sequence_maximum)?)

i.e. _sequence_minimum must be present, however, 
diffrn_standards_decay_% in cif_core.dic has an enumeration range of
':100'
which is a violation of this spec.

2.  _related_function has _list set to "yes", whereas _related_item
has _list set to "both".  In many places in cif_core.dic, these items
are not looped.  This violates the DDL1 spec. Furthermore,
_list_reference and _list_mandatory are specified for these two, but
these meanings are lost if these items aren't looped.  

A kludgy solution is to set _list to "both" for _related_function.
Kludgy, because then _list_mandatory and _list_reference lose their
usefulness unless they themselves are expanded to refer to the category
rather than to lists within the category.  The "right" solution is to
first change _list_reference to mean the same as _item_dependent in
DDL2, i.e. the item name(s) given in the _list_reference attribute must
be present in the data block (not the same list), and then drop
_list_mandatory (as there are only these two items in the category
_list_mandatory serves no practical function).     


On Wed, 2005-07-06 at 12:15 +0900, James Hester wrote:
> This is a "bug-fix" list for DDL1 which I hope would be orthogonal
> to any other plans for DDL1/2/3.
> 
> Ideas for tidying-up DDL1
> -------------------------
> (From the top of the DDL1 spec file working down)
> 
> _enumeration_range:  "can apply to 'numb' or 'char' items which
> have a preordained sequence"; is this meant to
> include Mon:Fri, June:Sept etc?  From a programming point of
> view the range of application needs to be circumscribed, and
> I would argue for restricting it to numbers only, which is consistent
> with use in current DDL1 dictionaries.  For small sets,
> such as letters, we can just list them.  We do this for the
> element symbols, rather than just write _enumeration_range 'H':'U'
> 
> ------
> 
> _list_reference: "...the data item(s) identified by _list_reference
> provide(s) a unique access code to each loop packet."  I originally
> interpreted this unique access code as a statement of usefulness rather
> than a requirement, but Nick indicated that such items *must* take
> unique values. Could this language be improved to make it clear that 
> the data item(s) *must* take unique values, and that if there are
> multiple values, the combination of each of the individual values must
> be unique in each packet, rather than each individual value.
> 
> ------
> 
> _list_uniqueness: "Identifies data items which, collectively, must have
> a unique value for the loop structure...to be deemed valid".  By
> inference from the single use in cif_core.dic, this should read:
>   "Identifies data items which collectively, together with the defined
>   data item, must have unique values..." 
>   
> In cif_pd.dic, the currently-defined dataname is explicitly given in the
> _list_uniqueness attribute, which would agree with the current DDL1
> spec.  
> 
> Alternatively to changing the DDL1 text, the single use in cif_core.dic
> could be edited to explicitly include the current data name
> (_publ_body_label). Some explicatory text about the relationship
> between, and intentions behind, _list_uniqueness and _list_reference
> would be useful too.
> 
> ------
> 
> _related_function: perhaps it could be made explicit that an 'alternate'
> data name can coexist with the defined data name in the same block?
> DDL2 have 'alternate exclusive' for the other case.
> 
> ------
> 
> _type_conditions: 'seq' is not used in any dictionaries DDL1 or
> DDL2.  Are there any reasons to keep it?  I note that *_gt and *_lt data
> names have appeared for situations that could have been covered by
> constructions of the type a:b. 
> 
> And as a programmer, it currently appears to be an extreme waste of time
> to implement 'seq', which would have to also include the case:
> data_some_data_name
> ...
>  _type             numb
>  _loop
>  _type_conditions  esd seq
> 
> which could mean 5, 5(1), 5,6,7  5(1):7(1) 5(1),6(1),7(1)
> are all possible values.  Supporting 'seq' also means that we have to be
> able to work with multiple data values for an unlooped data item,
> without any indication of which one is best, or what the different
> values might mean.  How could I do even basic arithmetic operations on
> such a data value??
> 
> 
> 
> _______________________________________________
> cif-developers mailing list
> cif-developers@iucr.org
> http://scripts.iucr.org/mailman/listinfo/cif-developers
_______________________________________________
cif-developers mailing list
cif-developers@iucr.org
http://scripts.iucr.org/mailman/listinfo/cif-developers