Discussion List Archives

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

Re: Opinions on comments as part of the content

Brian McMahon wrote:
> 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).
My feeling is that the simple approach is important. It is the main
advantage of a plain text format. If you cant hack it with vi, why not
just use a binary format? Even the Web uses JPEG/GIF binary for 'visual
array data'. The point of CIF, I thought, is to keep things human readable.

> 
> 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.

My view is that is is more sensible to redefine GLOBAL_ than to add on a
new hack for data_global. Either way, the rules have to change. I am
assuming that nobody else uses the STAR format, so that redefining
GLOBAL_ does not break anything, but I could be wrong.

If you want to actually define some sort of scope inheritance, why limit
it to a single magic data block? Wouldn't it make more sense to have
some sort of scoping directive within a data block (i.e inherit
data-block XXX). Of course, I am thinking in terms of CIF being mostly
self-described, and not completely dependent on a dictionary.

Joe

Reply to: [list | sender only]