Discussion List Archives

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

Re: Revised draft of CIF 1.1 syntax document

  • Subject: Re: Revised draft of CIF 1.1 syntax document
  • From: "Herbert J. Bernstein" <yaya@xxxxxxxxxxxxxxxxxxxxxxx>
  • Date: Fri, 13 Sep 2002 14:51:23 +0100 (BST)
I would for one suggest we allow (but not require) the use of stop_

On the semicolon question:

I would suggest we gain the most flexibility by saying that

'foo'

is equivalent to

;foo
;

since we still can represent 'foo\n'

by

;foo

;

If we were to say that

'foo\n'

is equivalent to

;foo
;

then we would be encouraging use of something like

;foo\
;

for an equivalent to 'foo'


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

                 +1-631-244-3035
                 yaya@dowling.edu
=====================================================

On Fri, 13 Sep 2002, Brian McMahon wrote:

> Thanks to all on the list who have made suggestions and critiques and
> pointed out errors in the draft 1.1 spec. I have posted a new version
> of the syntax document at
>    http://www.iucr.org/iucr-top/cif/developers/spec/cifsyntax.html
>
> For convenience of comparison, it retains deleted material in a red
> strikethrough font for the moment.
>
> I have summarised the substantial changes below. There are a couple of
> issues which I consider still open, and would welcome discussion on these
> before a final version is submitted to COMCIFS for approval. If no
> discussion is forthcoming within a few days, I shall submit the current
> draft as it stands to COMCIFS.
>
> (1) Is a useful purpose served by permitting the use of the STAR word stop_
> to indicate the end of a loop or loop header? Since CIF does not use nested
> loops, its use for this purpose is unnecessary. On the one hand it permits
> the general usage of the STAR stop_ directive in CIFs and (arguably) is of
> help in data recovery from broken CIFs; on the other hand it requires
> parsers to accommodate a new directive and track the context accordingly.
>
> (2) Should the value of a semicolon-delimited text field include the final
> end-of-line? If so, the following two cases have identical values: 'foo' and
> ;foo
> ;
> If not, the values are different: 'foo' in one case, 'foo\n' in the other.
>
>
>
> Para 5a. An implementation note is introduced to explain that saveframes
> have been introduced into the CIF specification to allow a single "CIF
> parser" to parse DDL2 dictionary files as well as data files. Since there
> is no way of distinguishing syntactically between dictionary and data files
> it is pointed out that an application-based parser that needs only to handle
> data files may legitimately flag the occurrence of a saveframe as an "error"
> (at the application level).
>
> Para 6. An error is corrected. A framecode (the name of a save frame)
> must be unique *within a data block*, but may recur in different data blocks
> within the same CIF.
>
> Para 12. The word 'reserved' is added to the description of '[' and ']' as
> "opening/closing delimiters".
>
> Also the discrete reserved words loop_, stop_ and global_ are itemised in a
> separate table from that describing forbidden unquoted substrings at the
> start of a data value.
>
> Para 19. The discussion of square brackets is changed to confer upon them
> the status of reserved opening characters.
>
> Para 22. Expanded to emphasise that VT and FF are excluded.
>
> Para 37a. Draws attention to the redundancy of <TextField> and
> <SemiColonTextField> at this revision and indicates the possibility of later
> introducing <BracketTextField>. As of now, other references to bracketed
> text fields are deleted (as indicated by red strike-through text).
>
> Para 42. Discussion of ways to handle machine-dependent <eol> across
> common platforms is prefaced wit the header "Implementation note:".
>
> Para. 51 and associated production. Removed production of <NameChar>
> pending further discussion on permitted character set in data names.
>
> Para. 59. Copied productions for <Exponent>, UnsignedInteger> and <Digit>
> as given in Appendix A summary table.
>
> Paras. 60 and 61 and associated productions. Amended to allow null files
> with whitespace/comments only and null data blocks to be formally valid.
>
>
> Brian
>


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

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

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