[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] Space as a list item separator
- To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] Space as a list item separator
- From: David Brown <idbrown@mcmaster.ca>
- Date: Mon, 30 Nov 2009 14:56:30 -0500
- In-Reply-To: <alpine.BSF.2.00.0911290910310.2441@epsilon.pair.com>
- References: <C735A4E4.12669%nick@csse.uwa.edu.au> <773849.42639.qm@web87014.mail.ird.yahoo.com> <alpine.BSF.2.00.0911270628060.81324@epsilon.pair.com> <434207.86524.qm@web87015.mail.ird.yahoo.com> <183781.58939.qm@web87001.mail.ird.yahoo.com> <279aad2a0911281945v4a7a3b37tf39ca4b45baf3478@mail.gmail.com> <455583.44145.qm@web87005.mail.ird.yahoo.com><alpine.BSF.2.00.0911290910310.2441@epsilon.pair.com>
Pleasse forgive me, everyone, but what is all this CIF1.5 about? Why do we need it? If a DDLm application is presented with with a CIF data file written using a DDL1 or DDL2 dictionary, which I assume uses CIF1.1 syntax, why can't we continue to use CIF1.1 since this works just fine for these files? Why do we need CI1.5? CIF data files written using DDL1 and DDL2 dictionaries do not contain lists and arrays because lists and arrays were not invented when these files were written, and any data files written with these dictionaries in the future (and there may be many of them) will still use the CIF1.1 syntax. There is no danger of arrays slipping into these data files unnoticed because they are not defined (and never will be) in DDL1 and DDL2 dictionaries (CIF1.1 does not allow it.) Of course our DDLm application (if we ever get it off the ground) will need to be able to read data files written with CIF1.1 syntax because we are required to ensure that this application can read in any existing CIF data file. It will also need to be able to read files written in CIF2 syntax because CIF2 will be needed for reading in the DDLm dictionaries (the only dictionaries that contain dREL) and the CIF2 data files (which may, unlike the CIF1.1 data files, also contain arrays and lists). As I pointed out earlier (and it seems to have come as something of a shock or epiphany to some), the DDLm dictionaries include very nice lists of aliases that contain every data name that was ever used for a given item. The data names in this alias list are, of course, quoted data values within the DDLm dictionary. and some contain characters that CIF2 would not recognize in a data name, but that is fine because they appear only in data values, and quoted data values no less, When confronted with a datafile written in CIF1.1, our hypothetical application would switch on its CIF1.1 lexer to read in the CIF1 data file, and pass the results into a preparser which would match the data name in the CIF1.1 data file with an alias name in the DDLm dictionary, and immediately substitute the DDLm data name for the original DDL1 or DDL2 data mame. Now all the problem with the old data names has disappeared. The preparser might have to make other changes to the data value (I am not sure that there are any, perhaps adding delimiters to all strings so they could be stripped away by the parser?). At this point you have a fully compliant CIF2-DDLm data set, which you can dREL to your heart's content. In particular, if dREL calls for an array, the item associated with that array will contain a dREL mothod for assembling the array from the individual data items that were originally stored in the input CIF and are now stored under a DDLm defined name. The only thing that would be difficult to do would be to reconstruct a DDL1 or DDL2 compliant data output file, but even this could be done if it was thought necessary. Please let's not make this exercise more confusing than necessary. You guys need to get on with defining what you want in CIF2. CIF1 can then look after itself using the existing tools together with the aliases for renaming the items. David Herbert J. Bernstein wrote: Dear Colleagues, |
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:idbrown@mcmaster.ca title:Professor Emeritus tel;work:+905 525 9140 x 24710 tel;fax:+905 521 2773 version:2.1 end:vcard
_______________________________________________ ddlm-group mailing list ddlm-group@iucr.org http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- Follow-Ups:
- Re: [ddlm-group] Space as a list item separator (Herbert J. Bernstein)
- Re: [ddlm-group] Space as a list item separator (SIMON WESTRIP)
- References:
- Re: [ddlm-group] Space as a list item separator (Nick Spadaccini)
- Re: [ddlm-group] Space as a list item separator (SIMON WESTRIP)
- Re: [ddlm-group] Space as a list item separator (Herbert J. Bernstein)
- Re: [ddlm-group] Space as a list item separator (SIMON WESTRIP)
- Re: [ddlm-group] Space as a list item separator (SIMON WESTRIP)
- Re: [ddlm-group] Space as a list item separator (James Hester)
- Re: [ddlm-group] Space as a list item separator (SIMON WESTRIP)
- Re: [ddlm-group] Space as a list item separator (Herbert J. Bernstein)
- Prev by Date: Re: [ddlm-group] Stakeholders
- Next by Date: Re: [ddlm-group] Space as a list item separator
- Prev by thread: Re: [ddlm-group] Space as a list item separator
- Next by thread: Re: [ddlm-group] Space as a list item separator
- Index(es):