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

Revised draft of CIF 1.1 syntax document

• Subject: Revised draft of CIF 1.1 syntax document
• From: Brian McMahon <bm@xxxxxxxx>
• Date: Fri, 13 Sep 2002 14:17:38 +0100 (BST)

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: Re: A formal specification for CIF version 1.1 (Draft)
• Next by Date: Re: Revised draft of CIF 1.1 syntax document
• Prev by thread: Re: CIF-DEVELOPERS digest 39
• Next by thread: Re: Revised draft of CIF 1.1 syntax document
• Index(es):
  • Date
  • Thread