[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: Backus-Naur descriptions for STAR and CIF
- Subject: Re: Backus-Naur descriptions for STAR and CIF
- From: Nick Spadaccini <nick@xxxxxxxxxxxxx>
- Date: Wed, 17 May 2000 16:03:40 +0100 (BST)
On Wed, 17 May 2000, Brian McMahon wrote: > Hence for CIF data files - as originally envisaged - the save_ and global_ > restrictions should apply; and Nick's BNF is erroneous. Yes, this and many other CIF restrictions are things I have not come to grips with yet - perhaps it is why I stick to STAR. The global_ structure was a feature of CIF dictionaries, but I had never really thought of CIF dictionaries not being themselves CIFs. But you are correct, and certainly the mmCIF dictionary is not a CIF, because of the save frames. I am happy to update the CIF BNF accordingly, if you give me the go ahead Brian. If I read you correctly the DDL1 based dictionaries will follow the same BNF except that one can explicitly enumerate the allowed datanames. > 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. I am not a fan of one STAR BNF and then defining the other formats as exceptions, because these are usually described in a loose fashion. A BNF can at least be specific about syntax - semantics are a different matter. On Wed, 17 May 2000, Bollinger, John Clayton wrote: > Thanks for the clarification. What about designating the end of looped > data with "stop_"? Without nested loops that is unnecessary, of > course, but it does not appear to actually be excluded. (And > Spadaccini's CIF BNF provides for it.) It is provided for within the BNF but not mandatory. Therefore its presence or otherwise still makes for a consistent CIF. > Well, an appropriate question would seem to be: "what is the purpose > of having a BNF representation?" I would argue that the principal > reason is to have a concrete, formal, precise definition of the > language(s) for reference purposes. Once we have a final BNF > representation for STAR, then, do we need additional BNFs for > restricted dialects of STAR? Is it less precise or concrete if we say > that a CIF, for example, is a STAR file that also satisfies certain > (specified) structural and syntactic constraints? In the cases of CIF, > DDL1, and DDL2, I don't think so. In my opinion, the nature of the > relevant constraints is such that specific BNF representations of those > languages wouldn't help us much more than the STAR BNF and the relevant > set of restrictions. Again my problem is in what form do you define these restrictions. English prose is expressive but unfortunately easily open to misinterpretation. A BNF on the other hand gives you a strong idea of the allowed syntactic constructs. By analogy we don't have one BNF describing imperative procedural programming languages, and then describe C, Fortran etc as a set of restrictions to that BNF. It is far easier to have a BNF for each language. The trick is, REDUCING the number of languages we are dealing with. cheers Nick -------------------------------- Dr Nick Spadaccini Department of Computer Science voice: +(61 8) 9380 3452 University of Western Australia fax: +(61 8) 9380 1089 Nedlands, Perth, WA 6907 email: nick@cs.uwa.edu.au AUSTRALIA web: http://www.cs.uwa.edu.au/~nick
Reply to: [list | sender only]
- Prev by Date: RE: Revision of IUCr policy statement on STAR/CIF
- Next by Date: Re: Backus-Naur descriptions for STAR and 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):