[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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:
--
Reply to: [list | sender only]
[ddlm-group] Managing deprecation in DDLm
- To: ddlm-group <ddlm-group@iucr.org>
- Subject: [ddlm-group] Managing deprecation in DDLm
- From: James Hester <jamesrhester@gmail.com>
- Date: Fri, 28 Apr 2017 11:11:36 +1000
- DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;h=mime-version:from:date:message-id:subject:to;bh=AL//HR6MYYn0WFrfxqpTSY9dQNEx6GX8UqDfU+enJ3w=;b=iLbSjdsYR0hBd24kXKoS1dgTiT8mLH9L5AOqaMu6iVwY0qjxOcAz1nW6sOQNIJXkr+jJcxO0crMyBZ5wURG98uwg2UaFJW99XIhaW0w7hBBq/mKmOK91XsL+PhDkEt12vaoV6YlChwHhIuuiY1IThT+K2ty20gNzodrTXCci5Tf2lteooEuZgkPtZs+p/AsTHkTYqlvp2tDvx2hEq6M5C+jniJ5ix5clBOEHz/bSCjqjbf2nOxxFlz9JBL8BZXIwQI0VlQdlwpK9Sjp3iOnGpZDmnQRkRBrNrk3ytaqcEocrxxWdg9RLs4r6uBtnfdS15XMEoi78stFMPVVPg0vFCQ==
Dear DDLm-group,
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.
--
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
F +61 (02) 9717 3145
M +61 (04) 0249 4148
_______________________________________________ ddlm-group mailing list ddlm-group@iucr.org http://mailman.iucr.org/cgi-bin/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- Follow-Ups:
- Re: [ddlm-group] Managing deprecation in DDLm (john.westbrook@rcsb.org)
- Prev by Date: Re: [ddlm-group] Treatment of CIF2 unicode characters with CIF1equivalents
- Next by Date: [ddlm-group] Some nitty gritty DDLm discussion taking place onGithub
- Prev by thread: [ddlm-group] Some nitty gritty DDLm discussion taking place onGithub
- Next by thread: Re: [ddlm-group] Managing deprecation in DDLm
- Index(es):