[also copied to openbabel, jmol and CDK - please be careful in replying]
At 13:15 03/05/2005, Miguel wrote:
> > (1) the hack that I have done may not be optimal. The idea is that the > Molpro xml is a superset of CML, so it makes sense to use the CML parser > in Jmol for those bits. Perhaps I did it in not the best way. It is also > not at all tested with files containing more than one set of geometries > or frequencies.
It makes sense for the MolproReader to subclass the CmlReader.
> (2) The molpro xml format is not yet set in stone, but will be soon: it > is not available in the currently released version of Molpro, but will > be in a version to be released in the next month or two. So there may > eventually be a need to modify or extend the interface in Jmol.
The problem of how to extend or contract CML is now important and I have literally yesterday created a white paper on extension and conformance. Henry will review it and then we would hope to release it very shortly.
The problem, obviously, is that uncontrolled extensions and variable semantics cause programs to crash. Moreover most programs only use a subset of the features of CML. We now believe that we have a simple robust mechanism which allows for creativity and innovation without crashing.
(a) no extensions within the CML namespace are allowed (if this were allowed it would be certain that we would get confusion and crashes). **The extensions must have a separate namespace.** So we are delighted to see extensions from Molpro and other codes IFF they are carefully managed in this way.
(b) much of the conformance can be checked with Schematron. This is almost trivial if you have an XSLT processor in your system (now standard with Java 1.5 - otherwise you will need Saxon). Schematron itself is an XSLT file of ca 15 Kbytes (sic) and the conformance tests for CML will probably be about the same size. This any program can call the CML Schematron and ask it "is my input conformant CML?"
(c) next - and I think this is very exciting - each *program* could have a Schematron, which decides what *it* can accept. Thus Jmol cannot render 2D coordinates in CML (or at least in one recent version it draws a "rotatable* flat molecule which it shouldn't). So a Jmol Schematron should assert that cml:atom/@x2 should not exist. And this can be extended to other XML files - including Molpro.xml, etc.
I am currently checking conformance against CML Schematron. I suspect that most current codes (including some of ours) will not conform. So this is a good time to make sure that we move towards this.
P.
Peter Murray-Rust Unilever Centre for Molecular Informatics Chemistry Department, Cambridge University Lensfield Road, CAMBRIDGE, CB2 1EW, UK Tel: +44-1223-763069 Fax: +44 1223 763076
------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
