Discussion List Archives

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

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

See responses below:

On Tue, Dec 22, 2009 at 1:01 AM, Herbert J. Bernstein <yaya@bernstein-plus-sons.com> 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.

Agreed.  There is potential for misunderstanding here which I will address in a separate reply.

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

Strongly disagree, for the same reasons as David.   The drive for this square bracket notation comes from support for legacy tags, which all start at 1, so it would seem capricious to then require a 0 starting index.  When you say 'remain' at 0, perhaps you are referring to dREL?   I strongly support leaving dREL with a starting index of 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]

You have now moved into discussion of DDLm attributes.  I'd prefer to put this aspect of the discussion off until we have an agreed syntax.
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

As for your point 1.4: it's clear that we can use DDLm to solve such problems, but first let's agree on the syntax.

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

Point 2 does not specify whether the data files are CIF1 or CIF2.  A CIF data file cannot contain tags that are syntactically excluded by the relevant specification (CIF1 or CIF2).  A CIF2 application can read a CIF1 file and convert it to a CIF2 file by applying aliases - is this what you intend?  I don't see what additional information your point 2 is supplying.

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
>                  +1-631-244-3035
>                  yaya@dowling.edu
>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

 Herbert J. Bernstein, Professor of Computer Science
   Dowling College, Kramer Science Center, KSC 121
        Idle Hour Blvd, Oakdale, NY, 11769

ddlm-group mailing list

T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
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.