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

Re: Backus-Naur descriptions for STAR and CIF

• Subject: Re: Backus-Naur descriptions for STAR and CIF
• From: Brian McMahon <bm@xxxxxxxx>
• Date: Wed, 17 May 2000 10:28:09 +0100 (BST)

Dear John

> My apologies, but lately as I peruse the CIF developers' tools and
> resources I am becoming confused about which STAR features are
> included in CIF and which are not.  I am particularly confused about
> save frames and global blocks.  Hall's original description of CIF,
> the one reprinted on the IUCr site, does not mark these features as
> excluded from CIF.  On the other hand, the vcif documentation refers
> to both as STAR features that are not part of CIF.  To make matters
> worse, Nick Spadaccini's new BNF description of CIF includes global
> blocks but not save frames.  If a more restrictive CIF specification
> has been adopted since 1991 then I have missed it; the specification
> adopted for use with version 2 core dictionaries appears to be less,
> rather than more, restrictive.  Am I missing something dumb?

STAR is a very general-purpose format, and its scoping rules are not always
intuitive (at least I find them running counter to my intuition). It was
decided from the start that CIF would use a restricted STAR format to
accommodate the usual programming practices of crystallographic programmers.

The specific restrictions were:
   No use of global_
   No use of save_ frames
   Loops no deeper than level 1
   Maximum line length (80 characters)
   Maximum length of datanames and datablock codes

The last restriction has been relaxed; there is no formal length restriction
on datanames and block codes, but in practice they are restrained by the
persistent 80-column record length. The loop level restriction was specified
in the Hall et al paper; I suspect the global_ and save_ condiitons were not
raised simply because the authors saw no point in drawing attention to
such features for the sole purpose of excluding them.

Hence for CIF data files - as originally envisaged - the save_ and global_
restrictions should apply; and Nick's BNF is erroneous.

CIF dictionaries are a slightly different case. For historical reasons their
early development was tied to a richer STAR application, and other STAR
features found their way into the dictionaries for one reason or another.
One such was global_ blocks: they permit a more compact representation of
data that can be set to default values in a large number of subsequent data
blocks. In due course, especially as the other STAR applications failed to
take off, COMCIFS decided that global_ would be removed from dictionaries
using the DDL1 definition language, to simplify the scoping rules within
dictionaries and allow them to be handled by existing CIF software. global_
is thus not found in any of the public dictionaries managed by COMCIFS.

The DDL2 dictionaries (especially the mmCIF one) were developed in a more
formal programming environment, and there it seemed appropriate - again for
scoping considerations - to encapsulate each definition within the
dictionary in a save_ frame. So the DDL2 dictionaries do allow save_ frames,
though they are not referenced through framecode pointers.

So where does this leave us? Do we need one BNF, for STAR, and then handle
all other cases as special, with different exceptions hard-coded? Or do we
need multiple BNFs (STAR, CIF, dictionaries - even DDL1 and DDL2
dictionaries)? There was some debate about this on COMCIFS a while back,
and we didn't really reach a conclusion. I think the answer will be a
pragmatic one, based on the needs of the software community. So this is an
opportunity to poll the list on just that point.

Regards
Brian

Reply to: [list | sender only]

• Prev by Date: RE: Backus-Naur descriptions for STAR and CIF
• Next by Date: Revision of IUCr policy statement on STAR/CIF
• Prev by thread: RE: Backus-Naur descriptions for STAR and CIF
• Next by thread: RE: Backus-Naur descriptions for STAR and CIF
• Index(es):
  • Date
  • Thread