<div dir="ltr"><div>Thanks David for the detailed explanation.<br><br></div><div>Part of the problem arises because DDL1 allows "both" as a description of the looping behaviour of a dataname.  The issues around the need to better describe the meaning of "both" resulted in the '_audit.schema' proposal last year. That proposal allows items that are not looped in the DDLm core dictionary to become looped in a controlled fashion, and I'd refer any interested parties to the finally approved proposal at <a href="http://comcifs.github.io/looping_proposal">http://comcifs.github.io/looping_proposal</a>.  <br><br></div><div>Given that DDLm forces us to clarify our thinking ("Set" or "Loop", but not "both"), the DDL1 dictionaries can be brought into line by also disallowing "both". Uses of '_list' = 'both' in the cif core dictionary (exptl_crystal_*, publ_author_*, audit_conform_*, space_group_*) can be inferred to have the meaning "looping is allowed, but if there is only one item you don't have to". Where looping doesn't have carry-over effects on other categories, these can become 'Loop' categories (publ_author, audit_conform). Where looping does have an effect (multiple space groups mean that multiple cells and multiple sets of atomic positions are also in theory required) we restrict these to 'Set' categories in DDLm and define a new '_audit.schema' to cover the looped situation.  <br></div><div><br></div><div>space_group_name_H-M-alt presents an additional issue, as it can be looped even for a single spacegroup, so should be a separate sub-category of space_group and is probably not suitable for the core dictionary in any case as it appears from David's comment to be of purely theoretical interest. I will adjust the forthcoming revamped DDLm symmetry dictionary accordingly.<br><br></div><div>I hope it is clear from this that we are not disenfranchising the theoretical community, but simply making sure that we don't stomp on each other's toes.<br><br></div><div>James.<br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 6 May 2017 at 05:31, Brown, David <span dir="ltr"><<a href="mailto:idbrown@mcmaster.ca" target="_blank">idbrown@mcmaster.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div>
<div style="direction:ltr;font-family:Arial;color:#000000;font-size:12pt">Perhaps an explanation why "space_group_name_H-M_alt" was defined as loopable is in order. When we put together the symmetry dictionary we were accommodating two schools with very
 different interest in symmetry. For most crystallographers symmetry is a convenient shortcut for defining all the atomic positions in the unit cell when symmetry is present, but there is another school that is interested in the theory of symmetry as a rigorous
 mathematical subject, and those of us who tend to be a little sloppy in our use of symmetry (see _symmetry_cell_setting as an egregious example) do well to pay attention to what the theorists tell us. They needed a unique reference setting to be defined and
 this is given in "_space_group_H-M_ref". The choice of reference setting is necessarily arbitrarily and is defined in its enumeration list.
<br>
<br>
Structure solvers choose the setting that is most natural to the structure they are describing. They are the people most likely to use CIF, but we wanted to make sure that the theorists could, for example, list all the settings for a given space group in the
 same CIF, as explained in the last sentence of section 3.8.2 in the original version of ITG. We therefore included "space_group_name_H-M_alt" as an opportunity for one or more non-reference settings to be given. This would require "space_group_name_H-M_alt"
 to be looped. It is hardly surprising that one does not find it looped in the Acta Cryst. database of structures, but I would be sorry to see its potential to describe symmetry in a more general and theoretical way excluded from CIF2. Its inclusion as a loopable
 item was deliberate and should  be respected.<br>
<br>
David<br>
<div><br>
<div style="font-family:Tahoma;font-size:13px">I. David Brown<br>
Professor Emeritus<br>
Department of Physics and Astronomy<br>
McMaster University<br>
Hamilton, Ontario, Canada<br>
</div>
</div>
<div style="font-family:Times New Roman;color:#000000;font-size:16px">
<hr>
<div id="m_8225077986220179956divRpF725138" style="direction:ltr"><font color="#000000" face="Tahoma" size="2"><b>From:</b> comcifs [<a href="mailto:comcifs-bounces@iucr.org" target="_blank">comcifs-bounces@iucr.org</a>] on behalf of James Hester [<a href="mailto:jamesrhester@gmail.com" target="_blank">jamesrhester@gmail.com</a>]<br>
<b>Sent:</b> May 3, 2017 01:02<br>
<b>To:</b> Discussion list of the IUCr Committee for the Maintenance of the CIF Standard (COMCIFS)<br>
<b>Subject:</b> Re: A managed phase-out of DDL1 dictionaries<br>
</font><br>
</div><div><div class="h5">
<div></div>
<div>
<div dir="ltr">
<div>
<div>
<div>Dear Matthew,<br>
<br>
</div>
We definitely need to take into account the significant investment of various groups in software based on the DDL1 framework. COMCIFS have guaranteed that datanames defined in DDL1 dictionaries retain the same meaning when appearing in DDLm dictionaries, so
 software that works with DDL1 datanames can function unchanged. If changes to the legacy dictionaries actually required you to spend any time rewriting software, then they are highly unlikely to be acceptable.  All changes will be drafted and published first
 in the Github repository (<a href="https://github.com/COMCIFS/DDL1-legacy-dictionaries" target="_blank">https://github.com/COMCIFS/<wbr>DDL1-legacy-dictionaries</a>), and I'd encourage you to monitor that and participate in discussions, particularly if any proposed
 changes would have a negative impact on your activities. <br>
<br>
A typical example of the types of changes being entertained would be "space_group_name_H-M_alt" being defined as loopable in the DDL1 core dictionary but strictly unlooped in the DDLm dictionary (discussed at
<a href="https://github.com/COMCIFS/cif_core/issues/20" target="_blank">https://github.com/COMCIFS/<wbr>cif_core/issues/20</a>).  Examination of public CIF corpuses (e.g. IUCr, COD) suggest that nobody has ever looped this dataname, therefore aligning it with the
 more rigorous DDLm definition would seem feasible.<br>
<br>
</div>
best wishes,<br>
</div>
James.<br>
<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 3 May 2017 at 01:24, Matthew Towler <span dir="ltr"><<a href="mailto:towler@ccdc.cam.ac.uk" target="_blank">towler@ccdc.cam.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-GB">
<div class="m_8225077986220179956m_4519057431969329745WordSection1">
<p class="MsoNormal"><font face="Calibri" size="2"><span style="font-size:11.0pt">Dear James<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri" size="2"><span style="font-size:11.0pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri" size="2"><span style="font-size:11.0pt">Thanks for the more detailed explanation.<span> 
</span>I agree with seeing what the state of the community is in two years rather than deciding now.<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri" size="2"><span style="font-size:11.0pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri" size="2"><span style="font-size:11.0pt">I remain slightly worried about the DDLm matching changes to DDL1 – as code that reads historic CIF already has to cope with quite a few different ways of specifying space groups
 (for example) and adding further improved methods will increase complexity.<span> 
</span>We may reach a point where parsing a CIF is simple, but writing code that will reliably interpret what is intended by the values in a majority of extant CIF requires quite a steep learning curve involving many previous versions of the dictionaries.<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri" size="2"><span style="font-size:11.0pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri" size="2"><span style="font-size:11.0pt">I am interested in understanding the benefits in back porting DDLm changes to DDL1, and the trade-off of these against the cost of change.
<span> </span>What I am wondering is whether it would be better to have DDL1 remain as-is, and keep the better representations only in DDLm; the advantage being that if DDLm support is being added to existing code, then that would also be a good point to add
 support for improvements in semantics.<span>  </span>Back porting to DDL1 risks imposes an otherwise unrelated change ahead of the need to add DDLm support, which might actually detract from the effort required to add DDLm support.<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri" size="2"><span style="font-size:11.0pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri" size="2"><span style="font-size:11.0pt">Best wishes,<span class="m_8225077986220179956HOEnZb"><font color="#888888"><u></u><u></u></font></span></span></font></p>
<span class="m_8225077986220179956HOEnZb"><font color="#888888">
<p class="MsoNormal"><font face="Calibri" size="2"><span style="font-size:11.0pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri" size="2"><span style="font-size:11.0pt">Matthew
<u></u><u></u></span></font></p>
</font></span></div>
</div>
<br>
______________________________<wbr>_________________<br>
comcifs mailing list<br>
<a href="mailto:comcifs@iucr.org" target="_blank">comcifs@iucr.org</a><br>
<a href="http://mailman.iucr.org/cgi-bin/mailman/listinfo/comcifs" rel="noreferrer" target="_blank">http://mailman.iucr.org/cgi-bi<wbr>n/mailman/listinfo/comcifs</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div class="m_8225077986220179956gmail_signature">T <a href="tel:+61%202%209717%209907" value="+61297179907" target="_blank">+61 (02) 9717 9907</a><br>
F <a href="tel:+61%202%209717%203145" value="+61297173145" target="_blank">+61 (02) 9717 3145</a><br>
M +61 (04) 0249 4148</div>
</div>
</div>
</div></div></div>
</div>
</div>

<br>______________________________<wbr>_________________<br>
comcifs mailing list<br>
<a href="mailto:comcifs@iucr.org">comcifs@iucr.org</a><br>
<a href="http://mailman.iucr.org/cgi-bin/mailman/listinfo/comcifs" rel="noreferrer" target="_blank">http://mailman.iucr.org/cgi-<wbr>bin/mailman/listinfo/comcifs</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">T +61 (02) 9717 9907<br>F +61 (02) 9717 3145<br>M +61 (04) 0249 4148</div>
</div>