Discussion List Archives

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

Re: Revised statement of policy on CIF

  Please note that the discussion has come around to the "IUCr see[ing] its
roles as the *maintainer of the STAR/CIF standard*"  There is a way to do
this so that we are truly supporting software development and do not run
afoul of various anti-trust laws.  Please consider getting involved in the
ISO approach to the development of standards.  This has worked very well
for programming languages.  If we are speaking of a STAR/CIF standard --
then let us create a real STAR/CIF standard.
  In Syd's hierarchy, I would suggest dropping dRel down to the same level
as DDL, and trying for two levels of metalangauge instead of three.  Two
should be enough.
  -- Herbert

At 4:27 AM +0100 3/30/00, Sydney R Hall wrote:
>Brian T's and John's comments are important.
>I do understand Brian's concern but I would worry about John's solution!
>At the risk of sounding like Herbert on the need for precise wording (:>)
>the use of "should be able" gives so much latitude to this statement that
>even I could "sail the Queen Mary" through it!
>I think the Brian's query goes to the heart of what I have been worrying
>about for sometime now... namely "what is a CIF and what isn't". I believe
>that we are lacking careful and well-understood distinctions between the
>various data handling processes (or languages) we have built and are
>building. In my view it is essential that we reach a common understanding
>on what is the difference between, for example, CIF data and a CIF dictionary.
>Specifically, by referring to "CIF conformance" do we expect that a parser
>has to handle save frames because they exist within DDL2 (and future DDL's),
>and, indeed, do we expect all CIF parsers to "understand" dictionaries and
>their attributes (DDL1 and DDL2)? I would say "no" but I am sure there will
>not be universal agreement on that within this group.. and I understand why!
>Here is a rather primitive attempt to make these distinctions.
>What we have in this field may be thought of as "layered concepts"...
>   0    STAR File   fundamental      STAR parser      StarBase
>                    exchange         in StarBase
>                    syntax
>   1    CIF         crystall.        CIF parser       Quasar... many
>                    appl. of
>                    STAR File
>   2    DDL1        dict. def.       DDL1 parser/     Xtal, ciftbx
>                    language 1       interpreter      ... many
>        DDL2        dict. def.       DDL2 parser/     ciflib, ciftbx
>                    language 2       interpreter
>   3    dREL        relational       dREL parser/     IDAS
>                    expression       interpreter
>                    language
>I have used the term "layered" because there are dependencies between
>the more advanced concepts and those in the lower layers. But I emphasise,
>as have others, that we shouldn't get too carried away by this model because
>it would not be difficult to separate the dictionary and dREL concepts from
>the CIF or STAR syntax requirements and still retain the overall
>In other words it would not be difficult to caste the dictionaries and any
>future developments into XML and still be able to process CIFs or any other
>universal files. Indeed, considering the growing commercial support for
>languages such as XML, this is a serious possibility. One, however, that I
>would like to offset, because, in my somewhat biased view, the CIF/STAR
>syntax is more concise and simpler to understand for the average scientist.
>By offset I mean that we strengthen the CIF/STAR role in future developments
>by making it very clear that IUCr sees its roles as the *maintainer of the
>STAR/CIF standard* and the *regulator of crystallographic* dictionaries.
>AND that it will promote, and perhaps even support, developments that will
>extend its capacity in this endeavour. MORE SPECIFICALLY it does not claim
>"ownership" over concepts such as DDL or dREL, or over software that are
>used in their implementation. I believe that it would be hard pressed to
>do otherwise, but it is *clarity* on this issue that is badly needed if
>we are going to entice developers and other disciplines into using this
>If we achieve this clarity developers can go about their business mindful
>of the standards and the regulatory role of COMCIFS for crystallographic
>dictionaries (and therefore the form the future *crystallographic* DDL's may
>take), but not be constrained in the scope of the tools they build for our,
>or any other, discipline.
>How does this sound as an "IUCr vision" for the future of data interchange?
>Cheers, Syd.
> syd@crystal.uwa.edu.au         ,-_|\       Professor Sydney R. Hall
>                               /     \      Director, Crystallography Centre
> Fx:  61(8)9380 1118       --> *_,-._/      Deputy Executive Dean of Science
> Ph:  61(8)9380 2725                v       University of Western Australia
> www.crystal.uwa.edu.au                     Nedlands 6907, AUSTRALIA.

****                BERNSTEIN + SONS
****     P.O. BOX 177, BELLPORT, NY 11713-0177
*   * ***
**** *            Herbert J. Bernstein
  *   ***     yaya@bernstein-plus-sons.com
 ***     *
  *   *** 1-631-286-1339    FAX: 1-631-286-1999