Discussion List Archives

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

Re: Permitting new physical units?

  • To: Multiple recipients of list <coredmg@iucr.org>
  • Subject: Re: Permitting new physical units?
  • From: syd@crystal.uwa.edu.au (Sydney R Hall)
  • Date: Wed, 18 Mar 1998 15:30:47 GMT
I don't have much time to spend on this tonight but I need to
respond quickly to David's last three mails before he builds
up a head of steam and disappears over the horizon (I can match
his mixed metaphors any day!).

David apparently needs reminding that the "dimensions" vs "units" 
debate raged in the earliest days of the DDL development. A decision 
was made to use the attribute "units". Since this embedded in the DDL
and will not be changed, it is really a waste of time debating it
further. In any case everyone understands exactly what it means.

David should be pleased that Nick Spadaccini is not copied into this 
discussion group because his reaction to the suggestion that an "@" 
separator be used in data names to give it special meaning would be
a lot less polite than mine. In my view this would be a totally 
backward step both from a theoretical and an application viewpoint.
The business of giving additional functionality to the data tag has 
been disposed of way back (e.g. the units extensions) for very good
reasons... it complicates the cif access (parsing) operations in a
number of respects. Such suggestions come forward from time to time 
because it seems at first sight to be a nifty idea to build functionality
into the data name. Take it from those at the sharp end of data handling 
processes this is NOT the case... it complicates handling for the 
programmer (what should to be done when _blat@shazam is encountered??)
and it detaches knowledge from the dictionary. We must agree once and for 
all that the attributes of data are a function of the dictionary, and 
that data names are simply identifiers. I can say quite categorically
that those working on the DDL and on future attributes will not deviate
from this basic premise.

The _units_construct and _units_default attributes are simple and 
effective ways to proceed with this problem. The programming of the
methods string is relatively trivial and will be part of future
releases of the ciftbx package... so programmers using this library
won't have to think about it. Other programmers worth their salt
will also have no trouble with this... once we define precisely what
the "methods syntax" will look like. We are working on that at 
the moment.

This particular comcifs discussion does raise the need for some 
collective discipline with such issues. Most core group discussions
will centre on defining new data items and adjusting existing ones.
All of us might have something to say about these, though usually
one or two will have the most experience and should be given their
head! However, the multiple definition problems such as posed by 
_refine_diff_density_* are more fundamental in nature in that they 
test the richness of the DDL. In such cases I hope that the technical 
advice given by those working on the DDL will be listened to.

Most of us don't have time for prolonged debate. Lets try to  
handle these matters as efficiently as possible and with the minimum
of air time. Life is short and there's still a lot to be done.

Cheers, Syd.

[Send comment to list secretary]
[Reply to list (subscribers only)]