This is an archive copy of the IUCr web site dating from 2008. For current content please visit https://www.iucr.org.
[IUCr Home Page] [CIF Home Page] [mmCIF Home Page]

Re: _item.mandatory_code can be undefined! (plus other development

Peter Keller (bsspak@bath.ac.uk)
Fri, 11 Aug 1995 11:51:50 +0100 (BST) 

> There is some history to this issue 

Yes, I thought that there might be....

                                    which is related to providing compliance
> to earlier dictionaries and CIFs.   It was agreed that in order to provide
> an easier integration with older dictionaries that there be a placeholder
> definition for every item in the mmCIF dictionary.  This really results
> in a large number of essentially redundant definitions for data items
> that are children of other items. In these cases only the definition of
> the data item and perhaps the item name have been specified in the mmcif
> dictionary. Placing a default value on the mandatory code would result
> in conflicting definitions for this attribute as in almost all cases these
> items are part of the key for the category in which they reside.  

Yes, I see - I hadn't quite realised the implications of this. I suppose 
that ideally there ought to be some kind of inheritance mechanism.....

                                                                 Rather
> that load up all of the definitions with an additional mandatory code
> attribute we have chosen to make this specification optional.  

OK, so as it stands, there are in effect four possible values of
_item.mandatory_code:  yes, no, implicit and undefined, with undefined
being the effective default. I have no fundemental problem with this -
just that there is no way of knowing, from publicly available information,
what an application is supposed to do with an item for which
_item.mandatory_code is undefined. At the very least, this issue should be
discussed in the documentation, and some sort of convention for dictionary
developers proposed. This kind of thing makes it very difficult for people
(like myself) who were not part of the original CIF/DDL effort, to write
effective and robust applications and libraries. In this particluar case,
if this isn't clarified, you risk running into what the compiler writers
call 'implementation-dependent behaviour'. It is very dangerous to rely on
the excercise of common sense by different people who are not in regular
contact, to produce consistent results! You have been warned! 

                                                            However,
> you will note in the mmCIF dictionary that it is provided all data
> items except in the case of redundant children.  

Actually, if you look, you will see that it is provided for all data items
_including_ the case of redundant children, as well as in their parent
item definitions. This is causing me problems, because there is nothing in
the DDL documentation about how multiply defined properties of dictionary
items are to be treated, and no mechanism (at least in publicly available
documentation) which ensures that conflicts don't arise. Ah, well, I
suppose that I shall just have to use my common sense....:-). 

The section on the ITEM_LINKED category points out (quite rightly) the
difficulties which can arise from cyclical linkages, but says nothing
about conflicts such as: 

save__cat1.name
    ....
    _item.mandatory_code    yes

    save_

save__cat2.name

    loop_
    _item_linked.parent_name  _item_linked.child_name
    '_cat2.name'              '_cat1.name'
    ...

   loop_
   _item.name      _item.mandatory_code
   '_cat2.name'    yes
   '_cat1.name'    no
   ...

   save_

Can I rely on SIFLIB (or other tools being used by dictionary developers)
ensuring that this kind of thing doesn't happen, or do I have to check for
this in my own applications? I think that those of us who are dictionary
users (i.e. CIF application developers) as opposed to dictionary
developers, should be told. 

Back to the common sense point. Those of you who were at Montreal, may
remember that I said that there must be a forum for developers to discuss
these, and other, issues, and to check their interpretations of the DDL
and dictionaries. An example - is there someone out there who can clarify
this point: 

_category.mandatory_code for the ITEM_TYPE category is no, i.e. it is not 
compulsory to define the type of a data item in a dictionary. So, if an 
application uses my library to request an item from a CIF file, and 
_item_type.code is undefined for that item in the dictionary, what is my 
library supposed to do? Refuse to process the item, and stop with an 
error? Assume a type of text, and let the application program sort out 
the mess? Or, have I misunderstood something? 

Sorry if I sound a bit tetchy. I might be in a better mood next week.
Peter.

========================================================================
Peter Keller.            \ 
Dept. of Biology and      \ "It is a pity that people are being killed
    Biochemistry,          \  by my guns"
University of Bath,         \ 
Bath, BA2 7AY, UK.           \          --- Mikhail Kalashnikov
------------------------------\-----------------------------------------
Tel. (+44/0)1225 826826 x 4302 | Email: P.A.Keller@bath.ac.uk (Internet)
Fax. (+44/0)1225 826449        |   P.A.Keller%bath.ac.uk@UKACRL (BITNET)
========================================================================