[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
DDL2/mm_CIF bugs/suggestions
- Subject: DDL2/mm_CIF bugs/suggestions
- From: James Hester <jrh@xxxxxxxxxxxx>
- Date: Tue, 19 Jul 2005 18:03:14 +0900
I'm thinking that the Volume G editorial process probably caught this first one: 1. In the ddl2 spec (filename ddl2.c96) note the following: --------------------------------------- save_ITEM_ALIASES _category.description ; This category holds a list of possible alias names or synonyms for each data item. Each alias name is identified by the name and version of the dictionary to which it belongs. ; _category.id item_aliases _category.mandatory_code no loop_ _category_key.name '_item_aliases.alias_name' '_item_aliases.dictionary' '_item_aliases.dictionary_version' save_ ------------------------------------- However, _item_aliases.dictionary_version has been replaced by _item_aliases.version (and all of the official DDL2 dictionaries use this) and no longer exists in the DDL2 spec, so obviously it cannot be a category key. I found this by trying to validate cif_mm_2.0.03.dic against ddl2.c96 - surely this is not the first time that this has been attempted?? 2. Regular expressions again. The regular expression for type "line" near the end of the cif_mm dic (version 2.0.03) includes "\n" but not "\r". Can I assume this is an omission? 3. A number of the regular expressions contain character classes between square brackets which include the sequence ".../\{}...". Python (and probably Perl, Tcl etc.) unfortunately interprets the "\{" sequence as an escaped curly bracket, and the backslash is thus lost from the list (this is in contrast to the POSIX regex standard which states that backslashes lose their meaning inside square brackets). When/if the regular expression in (2) is being updated, perhaps the \{ could be changed to a "\\{" for robustness as well? 4. If people are serious about using the cif_mm dictionary to validate files supported by cif_core, I would suggest some sort of mechanism to indicate when a dataname first appeared in the aliased dictionary (e.g. _item_aliases.version_first) rather than simply giving the version in which the dataname appears. As currently set up, the cif_mm dictionary will have to carry around a long list of aliases for each dataname, with one entry for every version of cif_core containing that dataname. _______________________________________________ cif-developers mailing list cif-developers@iucr.org http://scripts.iucr.org/mailman/listinfo/cif-developers
Reply to: [list | sender only]
- Follow-Ups:
- Re: DDL2/mm_CIF bugs/suggestions (Brian McMahon)
- Prev by Date: DDL1-DDL2
- Next by Date: DDL2 parent-child question
- Prev by thread: DDL2 parent-child question
- Next by thread: Re: DDL2/mm_CIF bugs/suggestions
- Index(es):