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.
Copyright © International Union of CrystallographyIUCr Webmaster