Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ddlm-group] CIF2 Syntax all wrapped up?

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 was then.

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. [5],
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 [5]
   _type.dimension_offset [1]

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

     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
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


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.

T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148

ddlm-group mailing list


fn:I.David Brown
org:McMaster University;Brockhouse Institute for Materials Research
adr:;;King St. W;Hamilton;Ontario;L8S 4M1;Canada
title:Professor Emeritus
tel;work:+905 525 9140 x 24710
tel;fax:+905 521 2773

ddlm-group mailing list

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.