Discussion List Archives

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

Re: Tidying up DDL1 (one added)

One more bug-fix suggestion for DDL1:

_item_name:  "...If data items are closely related, or represent an
irreducible set, their names may be declared as a looped sequence in the
same definition."

It is not clear whether this requires that all members of such a looped
sequence must be present (in the data block? in the same loop?).  While
"irreducible set" implies that all must be present, the implications
of "closely related" aren't spelt out.

James.

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