Replace hkl with opaque identifiers for reflections

[jamesrhester]

hkl are inadequate to identify reflections as twinning or incommensurate structures will cause them to be repeated. Note also that mmCIF already defines _diffrn_refln.id.

Changing the unique key for refln and diffrn_refln will not have any practical effect on legacy software as that software would have broken anyway in situations where hkl are repeated.

This fixes issue #499.

[vaitkus]

Looks good to me!

However, I wonder why the mmCIF dictionary defines the _diffrn_refln.id name, but not the _refln.id data name.

[jamesrhester]

However, I wonder why the mmCIF dictionary defines the _diffrn_refln.id name, but not the _refln.id data name.

I speculate it is because a typical CCD data collection will involve collecting many reflections at least twice (once in and once out of the Ewald sphere), so hkl is obviously inadequate as an identifier. However, reflections in REFLN are merged, so won't duplicate hkl in typical experiments.

[gmadaria]

Yes, hkls are good identifiers for merged reflections (merging redundant and symmetry-equivalent reflections is necessary before any solution or structural refinement). So, for mmCIF, a complete dictionary, and assuming that all macromolecular structures are periodic in 3D, everything is fine. Even if crystals are twinned, the twinning dictionary has implemented the solution. The problem appears for extensions of, for example, cif_core.dic. We are currently validating CIF1 and CIF2 files using the CIF2 core dictionary and appropriate extensions. It goes fine through aliasing. The problem appears during dictionary merging since the attributes for the extended tags are fixed by the first dictionary. In the case of modulated structures, we could merge in the order cif_ms.dic + cif_core.dic and all CIF files containing exclusively 3+d indices would be handled correctly. But if the file contains, as many deposited CIF files do, 3D and modulated structures, the 3D reflection list would not be valid. If the merge were cif_core.dic + cif_ms.dic, the result would be exactly the opposite. So, everything would be fine with the proper reflection identifiers. It is true that it would cause backward compatibility issues. To what extent methods, in practice, could alleviate this is something that interests us.