Discussion List Archives

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

Re: magCIF - policy advice requested

Dear All,

My take-away from John and Herbert's discussion is that both are happy with DDLm, John with the proviso that the loss of already available dictionary-driven functionality for DDL1 should not be too great. 

I strongly suspect that there is little functionality that would be lost in moving from DDL1 dictionaries to DDLm dictionaries, and let us not forget about the significant gains to be had from writing in DDLm. Why do I think this? Dictionary-driven applications for DDL1 are almost entirely restricted to validation of instance files for correct loop contents and dataname formatting.  These will continue to work on the non magCIF datanames in magCIF files. The only parts of DDL1 that it makes some sense to use at runtime by applications dealing with semantically correct instance documents are alias substitution and default value insertion. I think it is generally accepted that default values are dangerous, and there will be no aliases in a DDL1 magCIF dictionary as the datanames are all for new concepts, so there is no loss at runtime.  DDL1 validation is useful, but a small part of the DDL1 ecosystem - given a syntactically correct file, most programs appear to dive in and raise an error if the value is not what is expected, rather than running a complete validation against a dictionary on each file that is presented.

Validation has a useful niche for software authors in order to check that they are producing correct files, but given the simplicity of DDL1 and the limited complexity of the magCIF additions (a few extra loops) this is also not providing  anything that would save much time.  Balanced against this are all the rich possibilities available in DDLm, and I would argue that the Javascript tool presented by Doug last year is already a more useful tool than we ever could have had for DDL1.

Normalisation was then raised as an issue. When discussing normalisation, let's not forget that an instance document is not a database and as it is a static file even if it were a database it is already locked "forever".  As soon as we put cell volume and cell parameters in a single datablock, we created the possibility of conflicting information, so that boat has well and truly sailed and gone around the world a few times as well.   So I don't think that objection to DDLm is viable.

By the way, I plan to enhance PyCIFRW this month to include validation checks at least at the level of DDL1, and want to make a start on a nice DDLm authoring tool.

all the best,

T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
comcifs mailing list

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.