Discussion List Archives

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

Re: [Fwd: Re: Question about DDLm]

In response to David's comments I have a few small observations:

> COMMENTS BY DAVID BROWN
>
>  If I understand your suggestion, my scheme would be replaced by the
> following
>
>
> 1. Read in DDLm. In fact, since the program is specific for a particular
> version of the DDLm there is no reason why DDLm should not be incorporated
> into the program when it is compiled.  Any change in the DDL requires
> reprogramming anyway.

It is conceivable that a DDLm dictionary update could make
machine-readable changes without requiring human intervention (for
example, adding a method to derive _import.if_dupl from
_import_list.id), so in the most general case it is reasonable to read
it in rather than hard code it.  For DDL1 and DDL2 the DDL dictionary
could be hardwired (which I think means that the programmer referred
to the DDL dictionary specification when writing the program).

>  2.  The CIF is read in.  In addition to what is currently in the DDLm,
> there would also be the definition of an item _audit_dictionary that the
> program would expect to find in the CIF (rather than the CIF dictionary).
> This item, stored in the CIF, would be an image of the top domain dictionary
> complete with the necessary import statements.  The CIF is read, the
> _audit_dictionary is extracted and stored as the initial state of the domain
> dictionary.

This is indeed what I intended, although I think it would be
sufficient for this item to give the URI of the dictionary rather than
contain the dictionary itself.  External programs can check their
local dictionaries for one with the same URI before fetching.

>  3. The domain dictionary is expanded using the import statements found in
> this inital state..

Yes

>  4. The expanded domain dictionary is use to interpret the the remaining
> items in the CIF.

Yes

>  A couple of points here.  The user may have the lower level dictionries
> stored locally and may be working off-line.  The program would need to be
> able to find local copies of the dictionaries.  The user may also wish to
> import additional dictionaries in order to calculate properties that are not
> included in the virtual dictionary defined in the CIF.  I assume these
> features could be added as options in the program.

No problem doing this.

-- 
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
_______________________________________________
cif-developers mailing list
cif-developers@iucr.org
http://scripts.iucr.org/mailman/listinfo/cif-developers

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Council for Science (admitted 1947). Member of CODATA, the ICSU Committee on Data. Member of ICSTI, the International Council for Scientific and Technical Information. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

ICSU Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.