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.
David
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
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
[email protected]
=====================================================
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 protected]
http://scripts.iucr.org/mailman/listinfo/ddlm-group
|
