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

• Prev by Date: Revised draft of CIF 1.1 syntax document
• Next by Date: Re: Revised draft of CIF 1.1 syntax document
• Prev by thread: Revised draft of CIF 1.1 syntax document
• Next by thread: Re: Revised draft of CIF 1.1 syntax document
• Index(es):
  • Date
  • Thread