[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] CIF-2 changes
- To: Group finalising DDLm and associated dictionaries <email@example.com>
- Subject: Re: [ddlm-group] CIF-2 changes
- From: David Brown <firstname.lastname@example.org>
- Date: Wed, 11 Nov 2009 12:02:48 -0500
- In-Reply-To: <C7208339.123F8email@example.com>
- References: <C7208339.123F8firstname.lastname@example.org>
I must be missing something. I have followed all the discussion
about allowed and disallowed characters, which I find fascinating, but
what I think seems to be missing from this discussion is an
understanding of how a CIF datafile is read using a dictionary. The
problem of reading the dictionary is different. It contains only CIF2
datanames including those used in dREL. Period.|
If you think it is necessary to be able to used CIF1 datanames in dREL, then you must be expecting to write each method using CIF2 datanames, CIR1.0 datanames and CIF1.1 datanames, for a total of three different versions of the same expression. This does not include extra expressions using datanames that have been deprecated in favour of more suitable names .
Nick seems to feel that we must abandon the idea that a CIF2 application should be able to read the earlier CIFs directly although the ability to read both CIF1.0 and CIF1.1 was the primary requirement that drove COMCIFS to accept DDLm. It should not be abandoned lightly - if anything we should abandon dREL first. It was to accommodate the ability to read the archive CIFs that _aliases were introduced into DDLm.
So from my viewpoint (as a dictionary writer) we have the following options.
1 Abandon compatibility with CIF1 and require all the CIF1 datafiles to be converted to CIF2 files (if such a conversion is possible) before being fed into CIF2 application. I.e., we abandon the primary reason for introducing DDLm.
2. Allow CIF2 applications to read in CIF1 datafiles with all their non-conforming datanames, and duplicate all the methods to capture all possible combinations of CIF1 and CIF2 datanames (in general at least three versions of each method would be needed).
3. Make use of the _aliases in the CIF2 dictionaries to allow a CIF2 application to recognize any of the earlier CIF1 datanames and internally convert the name to the standard CIF2 dataname, which is also the (only) name that will appear in the dREL method. That is, we accept the multitude of earlier datanames and clean then up as soon as the old name is recognized.
Options 1 and 3 are similar, the difference being that option 1 requires a separate program to generate a CIF2 datafile which is then read in, while option 3 does the same thing as part of the CIF reading routine. Under option 3 therefore, the ONLY time that CIF1 datanames would need to be read would be during the input of the CIF1 datafile. After that all references would use the CIF2 datanames. A parser that could recognize the earlier datanames could certainly be used to read a CIF2 dictionary as well as a CIF2 datafile.
Option 3 is the most elegent way of handling the problem. In that way dREL never has to be concerned about embedded characters that CIF2 does not like.
Options 2, is the only option that would require datanames with the disallowed characters in dREL, but it is the absurd case of cutting off your nose to spite your face. It is a wonderfully comples solution to a problem that does not even exist.
Nick Spadaccini wrote:
begin:vcard fn:I.David Brown n:Brown;I.David org:McMaster University;Brockhouse Institute for Materials Research adr:;;King St. W;Hamilton;Ontario;L8S 4M1;Canada email;internet:email@example.com title:Professor Emeritus tel;work:+905 525 9140 x 24710 tel;fax:+905 521 2773 version:2.1 end:vcard
_______________________________________________ ddlm-group mailing list firstname.lastname@example.org http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- Re: [ddlm-group] CIF-2 changes (Herbert J. Bernstein)
- Re: [ddlm-group] CIF-2 changes (Nick Spadaccini)