[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Revised statement of policy on CIF
- To: Multiple recipients of list <comcifs-l@iucr.org>
- Subject: Re: Revised statement of policy on CIF
- From: Sydney R Hall <syd@crystal.uwa.edu.au>
- Date: Thu, 30 Mar 2000 04:27:33 +0100 (BST)
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"... LAYER LANGUAGE PURPOSE PROCESSOR "PRODUCTS" ------------------------------------------------------------------------------ 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 functionality. 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 standard. 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.
- Prev by Date: Re: Revised statement of policy on CIF
- Next by Date: Re: Revised statement of policy on CIF
- Prev by thread: Re: Revised statement of policy on CIF
- Next by thread: Re: Revised statement of policy on CIF
- Index(es):