[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
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

Reply to: [list | sender only]

• Follow-Ups:
  • Re: Tidying up DDL1 (last time?) (James Hester)
  • Re: Tidying up DDL1 (one added) (James Hester)
  • Re: Tidying up DDL1 (Matthew Towler)

• Prev by Date: RE: _atom_site_aniso_label is broken
• Next by Date: Re: Tidying up DDL1
• Prev by thread: DDL1-DDL2
• Next by thread: Re: Tidying up DDL1
• Index(es):
  • Date
  • Thread