Discussion List Archives

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

Re: Tidying up DDL1 (last time?)

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

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.

Useful links