Re: [ddlm-group] Proposal to enhance the behaviour of a DDLm "Set"category: please consider

I am currently working up a second proposal and pondering it from different angles before sending it out.

If imgCIF 'adds keys to categories' that could easily cause issues for software. For example, if you decide that a child key of 'scan.id' should be added to all categories that previously used only 'frame_id' as the key, any software that relies on a unique frame name to find a row will fail.  It wants 'frame 1' but there may be 10 'frame 1's.  I surmise that the only reason no problems have been encountered is that the intersection of files that include the new keys, and legacy imgCIF software that doesn't expect the keys, is exceedingly rare. If Herbert perhaps give an example of a key addition that occurred in the past that would help to confirm or refute this supposition.

all the best,

James.

On 6 June 2016 at 20:27, Herbert J. Bernstein <yayahjb@gmail.com> wrote:

  James has said:  "While this would work prospectively, it still doesn't fix the problem of old software that doesn't know about the new child keys. Adding new keys to a category unequivocally changes the meaning of all of the non-key datanames in that category, and old software will operate using the old meanings.  If this is a point of disagreement, I will write a blog post about it as I will need to use some pictures to explain why I think this."

  One major difference between imgCIF and mmCIF is the reliance in making use of "implicit" item.mandatory_code for the values of otherwise missing keys, so we are able to deal with the issue of categories with different key structures from mmCIF without having to define different categories.  In the intervening years since the creation of imgCIF, "implicit" seems to have dropped out of sight for other dictionaries, but it is heavily used in imgCIF because we are always dealing with information that will eventually have to end up in a database (the PDB), but at a stage for which the values to use for some keys are not yet known, or which may have to change.

  So in imgCIF we add keys to categories and, in addition, we fail to give explicit values to some mmCIF keys, and, as far as I am aware, this has not caused issues for existing software, nor does it seem to have changed the meaning of the non-key datanames yet, so I very much would appreciate James' offered blog post.  It would be very helpful in a dREL conversion of imgCIF.

  Regards,

    Herbert

_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://mailman.iucr.org/cgi-bin/mailman/listinfo/ddlm-group