RE: core_cif review note: _diffrn.crystal_id removed

Dear Core DMG,

In the course of removing unneeded keys (as per a previous email), I noted that the draft core dictionary is inconsistent as to whether or not multiple crystals are supported.   Referring to Vol G, the original DDL1 core allowed multiple crystals to be listed in exptl_crystal, and these crystal ids could be included in the diffrn_refln and refln lists.  The new draft core adds these crystal ids to the exptl_crystal_face category (not too problematic) and to the diffrn category. The latter is nominally a set category (one value per dataname in DDL1) and so couldn't refer to more than a single crystal id.  I have therefore removed crystal_id from this category in the updated draft, which now accurately reflects the state of the DDL1 dictionary.

Looking to the future, we do now have an elegant solution for handling multiple crystals, by making use of the new _audit.schema arrangement. In an ideal world, the core dictionary would assume only one crystal, and a small expansion dictionary associated with a non-default value of _audit.schema would define exptl_crystal.id and the keys listed in the previous paragraph.  In this ideal world, software that did not want to deal with multiple crystals could happily stick to the default schema.

It's not clear to me how much the multiple crystal definitions in the DDL1 core are actually used. It would be great to have some comments, especially from software authors, as to whether or not they input/output _exptl_crystal_id as defined in the current DDL1 core dictionary.  For example, would your software input and process CIFs correctly if the reflection list contained multiple instances of the same h,k,l, each from different crystals? Do you actually output _refln_crystal_id in the reflection list?

I am currently preparing a core CIF draft containing the various small revisions described in this and previous emails and should have it available for you by the end of the week.

all the best,

James.
--