Discussion List Archives

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

Tidying up DDL1

  • Subject: Tidying up DDL1
  • From: James Hester <jrh@xxxxxxxxxxxx>
  • Date: Wed, 06 Jul 2005 12:15:38 +0900
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

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:
 _type             numb
 _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

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.