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

Re: A formal specification for CIF version 1.1 (Draft)

• Subject: Re: A formal specification for CIF version 1.1 (Draft)
• From: Doug du Boulay <ddb@xxxxxxxxxxxxxxxxxxxxxxx>
• Date: Thu, 11 Jul 2002 10:44:00 +0100 (BST)

> File". To focus subsequent discussion on this list, I would invite you
> first to review and comment on the syntax specification at
>     http://www.iucr.org/iucr-top/cif/developers/spec/cifsyntax.html
> since this describes the syntax rules that all parsers must follow; some at
> least of the semantic content can be tailored to the needs of individual
> applications. However, the semantics document is also posted for
> information.

Just a couple of implementation questions about 
global blocks (syntax 33), 
handling of comments 
version identification (syntax 34)
Dictionary compliance (semantics 26-28)

Firstly syntax-33  
"use of the global__ feature of STAR is expressly forbidden at this revision"
I recall seeing a significant number of CIFs on the journals site containing
data_global This is just an interim placeholder right? And everything that
inevitably aught to go into a global_ block should temporarily be placed in 
such a data_global block for the interim?


Is there some protocol envisaged for treating CIF comments in order to
preserve intact the structure of the file between reading a CIF in and 
writing it intact, back out again? Should comments be 
associated in any formal manner with neighbouring pre or post data items or 
in the case of comments between data blocks, with a pre or post data block
or data_global placeholder(?). Alternatively, since it seems ambiguous, is 
there any thought about deprecating  # delimited comments in favour of more 
formal tag value constructs?


Version identification (syntax 34) and Dictionary compliance (semantics 26-28)

If you are going down the version identification path and adding an 11
byte header, why don't you go all the way and tack on a dictionary
compliance URI ala html/xml/sgml? Instead any generic CIF reading program 
that wants to read the CIF, and possibly associate it with some dictionary 
specific data structure, has to do an initial scan, probably of the entire 
file to find the dictionary conformance tags. Sure it can be done, but it is 
not optimal.

Kind of related, can a CIF contain a data_block that is version #\#CIF_1.1
compliant, as well a another data_block that is version #\#CIF_1.0 compliant?

And can a CIF (file or data_block?) really be totally conformant with more 
than one dictionary, i.e. why the need for item 27 loop_?  Would it not be
more accurate to specify a single dictionary against which the data contained 
is completely conformant? (the dictionary in question could specify its own 
conformance with other dictionaries more explicitly)

Also concerning Dictionary compliance item  28,
where and what is the detailed dictionary locating merging and overlaying 
protocol?

Also regarding the Character set (syntax 22-23) I was under the impression 
that by using ASCII you were already conformant with the UTF8 character set.
Any other unicode characters are instantly available, encoded using the 7bit 
ASCII character set  (try man -7 utf-8 on linux box). So why the need for 
restrictions?


Some of these things have nagged me in the past.
Cheers
Doug du Boulay

Reply to: [list | sender only]

• Prev by Date: RE: A formal specification for CIF version 1.1 (Draft)
• Next by Date: Re: A formal specification for CIF version 1.1 (Draft)
• Prev by thread: RE: A formal specification for CIF version 1.1 (Draft)
• Next by thread: Re: A formal specification for CIF version 1.1 (Draft)
• Index(es):
  • Date
  • Thread