Discussion List Archives

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

Re: Survey of available CIF software and request for wish list

  • To: Multiple recipients of list <comcifs-l@iucr.org>
  • Subject: Re: Survey of available CIF software and request for wish list
  • From: Nick Spadaccini <nick@cs.uwa.edu.au>
  • Date: Wed, 4 Oct 2000 07:17:09 +0100 (BST)
On Mon, 2 Oct 2000, Peter Murray-Rust wrote:

As a general note, looking at things from a STAR point of view, I have
never considered XML a exclusive competitor to STAR with respect to the
discipline domains that have adopted STAR or some derivative of it.
Certainly STAR is not a competitor to XML in wider web based applications.
I believe that discipline specific derivatives of XML (such as CML) can
and should coexist with STAR. It would be pointless not to leverage off
the XML based tools which are touted to be "just around the corner".

> XML seeing something I have already tried to tackle in CIF/STAR and 
> realising why I found it difficult! My analysis is that *semantically*, XML 
> and STAR are virtually identical.

Yes, I would think so, otherwise the universality of XML would be brought
into question. I think the new developments with respect to methods
included in the dictionary definitions, and then compiling the dictionary
into classes and object instantiations of those means we have moved on
significantly from the view of STAR/CIF/DDL as piles of text. The
dictionaries in our new system are executable, and any attempt to "access"
a data item results in the Java/Python object for that data item being
invoked. In this way all manner of validation, verfication and evaluation
can be done on data items. The Java/Python blend has worked for us because
both support "reflection" (the programmatic term, not the crystallographic
term), meaning that executable objects written in either code can be
pulled in at run-time.

I know all of this can be specified in XML but I think the generation of
an executable version of the XML based dictionary isn't going to result
from "tools", someone is going to have to knuckle down and write some
significant code.

> My own approach to CIF - which is the only one that I personally can write 
> code for - is to transform it into XML and use XML tools. This may seem 
> like heresy, but ... If I wish to use CIF/STAR syntax then I write DOM and 
> XSL-based converters in both directions.  This does NOT mean I abandon the 
> CIF effort - quite the reverse. In CML I specifically support the use of 
> ontologies (dictionaries) from IU's and other learned bodies and I put the 
> CIF dictionaries at the top. But I have to convert them to XML to make the 
> reading, editing, display, validation, etc. possible.

Doesn't sound like heresy to me. It sounds like astute and sensible re-use
of existing technologies to leverage up CIF/STAR as a usuable format.

> Apart from syntax (above) checking should involve:
>          document VS dictionary (equivalent to XML validation). not trivial
>          dictionary VS DDL       ditto but additional effort
>          DDL vs DDL

We do this is star. Infact everything is driven through the dictionaries,
the discipline specific dictionary and the DDL dictionary (the dictionary
that defines the DDL language)

> All these are equivalent to XSLT operations. For example, sorting a CIF is 
> not trivial.

What do you mean by "sorting a CIF"?

> I now use java because it is the lingua franca of the web and the first 
> tool for XML developers. It also comes with a huge library (e.g. Date, 
> Math, Collections, etc.) which simplify a lot of things.

We have focussed on both Java and Python. I think Java is more than just a
web language (though many will disagree) and I think it will probably
survive any onslaught from Mircosoft's C#. We use the reflection
capabilities of both languages to write code components in either

> No - please no! I have horror stories of TIFFs and GIFs for chemistry. 
> Sometimes when rescaled bits disappear and bonds can literally disappear. 4 
> can be transformed to +, etc.
> I strongly urge SVG - the new graphics language from W3C. it's gorgeous. 
> See http://www.adobe.com/svg for some examples.
> See also http://www.xml-cml.org

I had a quick browse of svg. Very impressive, but plug-ins are restricted
to WinTel and Macintosh. The fact that Adobe is behind it and given the
great job they have done with postscript and pdf I think svg is very
likely to be around for a while.


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