Discussion List Archives

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

Re: Opinions on comments as part of the content

A lot of good stuff in this discussion. One thing it brings out
is the dichotomy between the "simple" approach - stick a CIF in vi,
memorise the CIF dictionaries, stick in a few comments to remind
other readers why we've done something that way - and the "formal"
approach of mechanise all i/o with reference to dictionaries
and/or stylesheets. CIF sits astride both camps, albeit somewhat
awkwardly.  The editorial staff at the IUCr can edit and manipulate
small-molecule CIFs pretty well, and a generation of Acta C/E
authors can also do so, with varying levels of proficiency. The
editorial staff at RCSB can even do it with mmCIFs, but the
complexity of a full structure description in an mmCIF stretches
people to the limit, and in collections of data sets, whether
coreCIF or mmCIF, we really do need formal validation mechanisms.

There are clear similarities between the hand-edited HTML pages
of the early web, and the schema-driven content management systems
of today's big Web applications. And perhaps, as on the Web, one
needs to be able to support both approaches.

It may be that the next cycle of major CIF development will
be able to produce a cleaner implementation that is essentially
fully dictionary-driven: but there will still need to be legacy
support for the archival CIFs (or a major effort to remediate
all existing CIFs to a cleaner form).

Enough philosophy - but it's relevant to my next comment. Joe wrote:

> I know that global_ is not part of CIF, but neither is this hack for
> using data_global. CIF says global_ is reserved for possible future use.
> Obviously people want a global_, so let's include it.

If you read Chapter 5.2 of International Tables G carefully,
you will see that the semantics of global_ inheritance in STAR are
actually rather subtle (especially if you also have save_frames
in a STAR file). Although one thinks one knows how to use global_,
I suspect it would be very easy to introduce unexpected inheritances
or context faults, particularly in typical FORTRAN programs or in
manual vi editing. Among other things, it breaks the ability to easily
re-order data blocks. Peter's probably correct that the implied semantics
of data_global are dangerous (although everything should work OK in
Acta CIFs, since care is taken to partition the data names between
blocks in a way that should circumvent collisions of data name). I
still think it would be better to resolve this dilemma by formally
relating the purpose of distinct data blocks in an AUDIT_... category,
rather than by opening the doors to the elegant, but rather dangerous,
global_ block.

Brian

Reply to: [list | sender only]