[ddlm-group] Managing deprecation in DDLm

In the case of direct dataname equivalents, '_alias.deprecation_date' is suitable as a way of flagging deprecation.  However, if there is no one-for-one substitution, there is no easy way to deal with deprecation. For example, on the cif_core discussion list we have been talking about how to deprecate _cell_symmetry_setting, which has no direct equivalent in the new core dictionary.  Having no equivalent clearly requires that we keep the dataname in the dictionary in order to interpret legacy files. For such definitions, it would be good to (i) have an attribute that directly flags deprecation (ii) where an algorithm exists to convert values to an alternative dataname (e.g. unit conversion), that this algorithm could be specified. While such deprecation happens very rarely, it would seem prudent to allow for occasional mistakes in dataname definition. 

Note that in DDL2 the _item_related.function_code dataname has values that indicate deprecation (Vol G table 2.6.5.1) and conversion by multiplication: "replaces", "replacedby", "conversion_constant", "conversion_arbitrary".  This is not a particularly good match for us, as simple replacement is already accomplished by aliases, and simple constant multiplication is not always sufficient.  We also have dREL at our disposal for describing arbitrary transformations.

I propose the following:

(i) a new DDLm attribute '_definition.replaced_by' which would have the value of a dataname that should be used instead (or default value 'None').

(ii) a new DDLm '_method.purpose' tag 'FromDeprecated' which could be used in the definition of the dataname that replaces the deprecated definition. The method associated with this purpose would calculate the value of the new dataname from the old dataname (and any other datanames that are necessary).

Does this scheme seem reasonable to you?  If so, I will work up a proper definition.

all the best,

James.

--