[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] CIF2 Syntax all wrapped up?
- To: Group finalising DDLm and associated dictionaries <firstname.lastname@example.org>
- Subject: Re: [ddlm-group] CIF2 Syntax all wrapped up?
- From: David Brown <email@example.com>
- Date: Mon, 21 Dec 2009 10:33:19 -0500
- In-Reply-To: <firstname.lastname@example.org>
- References: <email@example.com> <alpine.BSF.firstname.lastname@example.org><email@example.com>
The only thing I would ask for is that the indices that appear in
the CIF be the same as those that are in current crystallophic use.
For most space related arrays the indices would be 1,2 and 3 rather
than 0,1 and 2. I can forsee all kinds of problems if we do not use
the indices that people are familiar with. For the forseeable future
people will continue look at and interpret raw CIFs because they are
easy to interpret. This was one of the original criteria around which
CIF was structured and it was a main reason that CIF was accepted by
the community, although I agree that the need is not as great now as it
I note that even if the zero convention is adopted as the default (as proposed by Herbert), it can be overridden by the dictionary. I would expect most arrays would be defined in the dictionary as a starting at 1. My vote would be to make this the default.
Herbert J. Bernstein wrote:
Proposals related to special characters in CIF2 tags: 1. implicitly defined element tags 1.1. For any CIF 2 tag that defines an array or a list the appearance of the array or list definition in the dictionary would implicitly also define tags for each of the array or list elements using the square bracket notation. 1.2. The implicitly defined tags would not be explicitly defined in a dictionary except to the extent needed to define aliases from CIF1 dictionaries for individual elements. 1.3. The default starting index would remain 0 1.4. Dimensions would be specified either as single numbers, e.g. , in which case the starting index would be 0 and the last index would be one less than the given dimension (i.e. C-style indexing), or as a range, e.g. [1:6], in which case the starting index would be the first member of the range and the last index would be one less than the second member of the range (i.e. a python-style range). Alternatively, an offset could be specified as _type.dimension_offset, so that _type.dimension  _type.dimension_offset  would be equivalent to _type.dimension [1:6] 1.5. In order to allow alliases to be defined for the individual implicitly defined tags, _alias.definition_list would allow a list of individual aliases to be specified for an array or list 2. Data files could contain tags that are from any of the following sets: 2.1. Tags explicitly defined in a CIF2 dictionary 2.2. Tags implicitly defined by proposal 1, above 2.3. Tags defined in CIF1 dictionaries according to CIF1 rules and linked to a valid CIF2 tag name via the aliasing mechanism. In order to implement this proposal, the lexical scan for a tag in CIF 2 would have to scan for a tag per se according to CIF1 rules. A validating parsr would then check that potential tag against the soecified dictionaries to see if it satisfied one of the rules on item 2. If it did and was an alias, it would be converted to the equivalent CIF2 tag for any further validation against the dictionary (i.e. DDLm methods would _not_ handle CIF1 tags). At 6:13 AM -0500 12/21/09, Herbert J. Bernstein wrote:In view of the many messages in that last thread that included boht syntax and reasons forthe choices, it might be a good idea to recap the syntax portion ofthat dicussion: 1. It begain on 9 Deb ith Biran asking us to reconsider allowing punctiation characters in data names. 2. I responded by suggesting allowing _all_ non-conflicting punctuation in data names. 3. David Brown focused the discussion on square brackets 4. John Westbrook also asked for square bracket support 5. James and Nick opposed including any additional characters 6. After a long exchange about aliases, I suggested we simply extend the definition of all array and list tags to include the automatic definition of the tags referencing their elements as a way to bring in the square brackets 7. David and Joe agreed on the need for square brackets 8. John agreed with the automatic definition of the tags for the elements 9. There was a discussion of the initial index issue and how to specify an initial index -- with a tag or with a range or both 10. Nick initially opposed the idea of automatically defining the element tags, but yielded, provided we did not define the element tags explicitly in the dictionary 11. James then supported the idea under the mistaken assumption that Nick had proposed it. 12. Nick then opposed the idea of having a starting index So where we are is: There now seems to be general agreement that when we define an array or list in the dictionary, all the element tags will automatically be available to the users We still have not settled on how/if to specify the necessary starting index, with the following alternatives on the table: 1. Don't specifiy the starting index array-by-array, just lock it in at 0 or 1 for all arrays and lists; or 2. Do specify the starting index with a range or with a separate tag or both. I support allowing an array-dimension by array-dimension specification of a starting index. I can live with either a range or a separate tag or both. -- Herbert ===================================================== Herbert J. Bernstein, Professor of Computer Science Dowling College, Kramer Science Center, KSC 121 Idle Hour Blvd, Oakdale, NY, 11769 +1-631-244-3035 firstname.lastname@example.org ===================================================== On Mon, 21 Dec 2009, James Hester wrote:Dear DDLm-ers, Am I correct in assuming that everyone is satisfied with the square-bracket syntax recently proposed by Nick? If so, I believe there is only one significant outstanding issue, that of being allowed to put whitespace between the key and the full colon, and the full colon and the value, in a table. I agree with Joe that no extra syntactic complexity is introduced by allowing (not mandating) whitespace to appear in these locations. If nobody objects, I would like to suggest that we alter the standard to allow such whitespace. James. -- T +61 (02) 9717 9907 F +61 (02) 9717 3145 M +61 (04) 0249 4148_______________________________________________ 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]