Re: [ddlm-group] Dictionary versioning
- To: Group finalising DDLm and associated dictionaries <email@example.com>
- Subject: Re: [ddlm-group] Dictionary versioning
- From: "Bollinger, John C" <John.Bollinger@STJUDE.ORG>
- Date: Mon, 24 Jul 2017 14:02:10 +0000
- Accept-Language: en-US
- authentication-results: spf=none (sender IP is )smtp.mailfrom=John.Bollinger@STJUDE.ORG;
- DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SJCRH.onmicrosoft.com; s=selector1-stjude-org;h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;bh=GU0D6wYEGytc86e+3ZQjoEVTUoRAnt/h2A/UWLgmxkk=;b=KWLdMKECdYBGfrM8dwjEOoeauToNYBEo55lQxikjrMtzFVirr8LUbNcAuU3eVeBnu3hJUKzrumCDu+XdEzYdom6Vub1HSmUkJLkKdAO51yy0tl/yoIfMlAzCMs/f0DWpPrDVjOwswK4xm+0tZQDS67w9v5AM398hUzwOt/hKdE0=
- In-Reply-To: <CAM+dB2c+NLiumpiwHyd6Dx7phPnHt0hi2h2eJ0U868dgoybzww@mail.gmail.com>
- References: <CAM+dB2c+NLiumpiwHyd6Dx7phPnHt0hi2h2eJ0U868dgoybzww@mail.gmail.com>
- spamdiagnosticmetadata: NSPM
- spamdiagnosticoutput: 1:99
Dear DDLm group,
I completely agree with James’s suggestion to use semantic versioning as the basis for dictionary version numbers. These principles are probably familiar already to most people on this group, but some may be unaware that there is an actual standard-ish document describing them, published at http://semver.org/. As presented there, semver is focused on software versioning, but inasmuch as the purpose is determining and managing compatibility between separately-maintained, interdependent software components, I don’t think it’s much of a stretch to apply them to separately-maintained, interdependent data components, such as CIF dictionaries.
As for the behavior of combining dictionaries to form a composite, we now have two procedures for that: the dictionary merging protocol, documented in ITvG 220.127.116.11, and DDLm’s importing facility. I suppose James uses the term “import” specifically in reference to DDLm’s import mechanism, but we should not neglect the dictionary merging protocol. If we don’t want to give it any other consideration then we should at least say that the rest of this discussion, and in particular the principles for assigning version numbers to dictionaries, are specific to DDLm dictionaries. If that were the direction we went, then I would furthermore recommend deprecating the dictionary merging protocol for use with DDLm dictionaries.
As far as the behavior of DDLm importation when existing and imported attributes collide, we should clarify exactly what situation or situations that would be. Since the issue is couched in terms of attributes, not whole definitions, I suppose we must be talking about an import defined with
, else there is no scope for an attribute-level collision. Is that correct? If so, the question seems to assume that the associated value of _import_details.if_dupl is not relevant in that case. Such an assumption is consistent with the letter of that item’s definition, but seems perhaps contrary to its spirit. If this is the path we are traversing, then I think we should clarify the meaning and applicability of _import_details.if_dupl as a threshold issue for the rest of this discussion.
For reference, I’m looking at the current version of DDLm as published on the IUCr web site, version 3.11.09.
John C. Bollinger, Ph.D.
Computing and X-Ray Scientist
Department of Structural Biology
St. Jude Children's Research Hospital
(901) 595-3166 [office]
From: ddlm-group [mailto:firstname.lastname@example.org]
On Behalf Of James Hester
Dear DDLm group,
The vagueness of dictionary versioning has been raised as an issue (see
https://github.com/COMCIFS/cif_core/issues/47). Now that dictionaries can import template dictionaries, it becomes possible that the template dictionary could change in ways that would render the main dictionary incorrect, for example, if a necessary attribute
was removed from the template definition. Such fiddling with template attributes has recently been proposed (see
https://github.com/COMCIFS/cif_core/issues/42) as a solution to certain technical issues.
Feel free to respond either on the github issue or here.
T +61 (02) 9717 9907
Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer
_______________________________________________ ddlm-group mailing list email@example.com http://mailman.iucr.org/cgi-bin/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- Re: [ddlm-group] Dictionary versioning (James Hester)
- [ddlm-group] Dictionary versioning (James Hester)