[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] Data-name character restrictions - one last time
- To: Group finalising DDLm and associated dictionaries <email@example.com>
- Subject: Re: [ddlm-group] Data-name character restrictions - one last time
- From: David Brown <firstname.lastname@example.org>
- Date: Wed, 09 Dec 2009 14:29:49 -0500
- In-Reply-To: <email@example.com>
- References: <20091209144035.GB29341@emerald.iucr.org><firstname.lastname@example.org>
I would suggest that we add CIF2 data namea as aliases in the DDL1 and DDL2 dictionaries for those few items where the names differ. This would mean that any DDL1 dictionary would recognize all the CIF2 data names that corresponded to items appearing in the DDL1 dictionary. Of course files with arrays could not be read this way, and adding arrays to DDL1 dictionaries would violate the DDL1 rules and would essentially convert the DDL1 dictionaries into non-conforming DDL2 dictionaries, thus defeating the goal of being able to read CIF2 data files with DDL1 software. Adding DDLm aliases to the DDL1 dictionaries would be easy since we would need to add less than a dozen aliases (but we would have to know what the DDLm data name is, or is going to be). Of course there is also the _ versus . problem with the data names. Adding '.' data names as aliases in the DDL1 dictionaries would get around that problem. It would be straightforward to add these, but it would be a larger job since all the data names would need an added alias. Even this will not help with legacy software using hard coded data names, but this might just encourage people to write a front-end that uses the dictionaries for input.
There is still the problem of the data names in DDL2 dictionaries that include . Adding an alias name that does not use these characters may allow DDL2 programs to read CIF2 data files, but CIF data files containing these  data names would require a CIF1 parser (and lexer?), so we just need to recognize this fact and live with it. In any case a CIF1 lexer should always be an optional front-end to a DDLm dictionary if it is to read in legacy data files as required by the specifications.
It would not be straightforward for a DDLm program to output a CIF1 data file, but is this really necessary? Once one has started to use the features of CIF2 one would probably wish to output items that do not even exist in CIF1. If one needed a fully compliant CIF1 data file in order to make use of legacy software, it might be better to write a CIF2 file, but restrict the items to those that exist in the DDL1 (or 2) dictionaries (this information can be found from the aliases in the DDLm dictionaries). The DDLm data names that would appear in this data file are either identical to the DDL1 data names or would appear as aliases to the DDL1 dictionary as described above.
As for recognizing CIF2 data files, isn't that what the magic code is for? If someone chooses not to use the magic code their CIF2 data file is non-conforming and they can expect difficulties. Most of the CIFs in DDL1 are initially prepared by computer and only the text being added by hand. Once the computers start generating CIF2 data files, they will be programmed to add the magic code.
Herbert J. Bernstein wrote:
Personally, I would greatly prefer to allow all data names that do not create a major lexer/parser conflict to appear in a data CIF and only apply the strong restrictions to data names that appear in CIF2 dictionaries as defined data names (not as aliases). -- Herbert At 2:40 PM +0000 12/9/09, Brian McMahon wrote:I have one remaining niggle that I'd like to revisit before we put this finally to bed. As has been mentioned a couple of times recently, restricting the data-name character set does invalidate syntactically many existing CIF 1 files (e.g. _refine_ls_shift/esd_max ). We have discussed strategies for handling this, and I think these are workable strategies, but will involve investment and hence expense in workflow management in CIF archives. I understand the rationale behind this restriction is to simplify future processing of data names in areas such as dREL applications. The question really is whether we're choosing the right trade-off in making things cleaner at that end of the processing chain. I would suppose that a dREL or other application could ingest a data name with dangerous characters, convert it internally into a "safe" identifier that's used for all processing, and then restore the original form upon output; but writing that intermediate layer of processing is of course expensive (especially if there aren't readily available libraries that will do this transparently). I suspect that some of the original proposed syntactic changes also had the effect (whether by design or collaterally) of simplifying i/o, data structure management, symbol table processing etc., but those may have suffered in the subsequent revision exercise we've just been practising. Given the consensus we are now approaching, would the code builders now be prepared to incur the addition expense of handling "dangerous" data names? I really don't want to spark off a long discussion on this - if a quick round of response shows that there's no appetite to allow the additional punctuation characters in data names, I'll accept that gracefully. *** One last comment while I have the floor, though it is related in part to the above question. A concern raised in the editorial office was that there would be circumstances where users didn't know if they were dealing with a CIF 1 or 2 ("users" meaning authors, perhaps resorting to the vi editor - and we're imagining most of them are dealing with small-molecule/inorganic CIFs). My supposition is that the IUCr editorial offices would only want to use CIF2 seriously in association with DDLm dictionaries, and that we would expect the revised core dictionaries to use the dot component in data names to signal this further evolution. So even a superficial glimpse of the middle of a CIF would make it clear whether it was CIF1 or CIF2. Does that fit in with how others see this progressing? Cheers Brian _______________________________________________ ddlm-group mailing list email@example.com http://scripts.iucr.org/mailman/listinfo/ddlm-group
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:firstname.lastname@example.org title:Professor Emeritus tel;work:+905 525 9140 x 24710 tel;fax:+905 521 2773 version:2.1 end:vcard
_______________________________________________ ddlm-group mailing list email@example.com http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- [ddlm-group] Data-name character restrictions - one last time (Brian McMahon)
- Re: [ddlm-group] Data-name character restrictions - one last time (Herbert J. Bernstein)
- Prev by Date: Re: [ddlm-group] Data-name character restrictions - one last time
- Next by Date: Re: [ddlm-group] Data-name character restrictions - one last time
- Prev by thread: Re: [ddlm-group] Data-name character restrictions - one last time
- Next by thread: Re: [ddlm-group] Data-name character restrictions - one last time