Discussion List Archives

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

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

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
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
>                  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.
>>
>>James.
>>--
>>T +61 (02) 9717 9907
>>F +61 (02) 9717 3145
>>M +61 (04) 0249 4148
>>
>
>_______________________________________________
>ddlm-group mailing list
>ddlm-group@iucr.org
>http://scripts.iucr.org/mailman/listinfo/ddlm-group


-- 
=====================================================
  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
=====================================================
_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group

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.

Useful links