Below is the CMLRSS feed of Chemical blogspace.

Of course, publishers can take advantage of such modules, using the XML Namespaces technology. The best practices uses that for a Dublin Core and a PRISM extension. The here discussed CML extension is another one, but the point is, that you can basically plug in any module.

Instead, PMD is given nice overviews of what it believes to be wrong with the CDK, and also provides a decent XML format which allows extraction of information, which is used by, for example, SuperNightly as showed yesterday in PMD 2.4.5 installed in the CDK 1.2.x branch.

I have been pondering about it for a long time now, but writing a JavaDoc checking library is hardly core cheminformatics research; at least, you would not get funding for it, despite everyone always complaining about good documentation. Alas.

Last week, I was reviewing some more code, and again saw the very common error of the missing period at the end of the first sentence in JavaDoc. This one is sort of important for proper JavaDoc documentation generation, but the complexity of the current DocCheck reporting, people are not familiar enough with it. Being tired of having to repeat myself, I decided to address the problen, but creating better Nightly error reporting for the CDK JavaDoc.

So, I started OpenJavaDocCheck, or ojdcheck. As mentioned, I have made quite promising progress, and the current version provides the ability to write custom tests (which I plan to use for validating content of CDK taglet content), and create XML as well as XHTML which can be saved to any file. To give you a glimps of where things are going, here’s a screenshot of the current XHTML output:

The current list of tests is really small, and consists of a single test:

• test if each class and method has JavaDoc

• Details behind the “Calling XMPP cloud services from Taverna2”
• Calling XMPP cloud services from Taverna2
• Next generation asynchronous webservices

So, I set up XMPP services for QSAR descriptor calculation, 2D diagram and 3D geometry calculations and a few more, using the CDK. Chemical Markup Language has been my primary choice for some 10 years now (see Peter’s blog) as it allows me to do things I cannot do in other formats.

Now, our XMPP services publish themselves what data types the allow as input and what they output in return. They do this by publishing XML Schema to describe the input and output types. My CDK services use CML, so they return the CML schema. Johannes’ xws4j implementation of the IO-DATA specification has an add on that can build bindings to the schema on the fly. Now, CML comes with a good XOM-based binding (called CMLXOM) so this is not strictly necessary, but for less common schemata it is worthwhile: you can always create bindings for brand new schemata, for older versions, for whatever. Services can even create their own local schemata, and people will still be able to easily use them. This is to me a big plus for this architecture.

Anyway, while CMLXOM exists, we wanted to show that the on-the-fly creation of bindings works, even for large schemata, such as CML. However, one of the older flavours had an small error in a regular expression in a data type CML defines. Johannes therefore asked me to test building bindings for the CML schema version used in my services. He adviced me to use scomp for this, which is a command line utility around the XMLBeans library used for the binding generation.

As I am running Ubuntu, I preferred installing the packaged version instead of installing the binary provided by XMLBeans. Now, after I did this, I noticed that this .deb did not install the scomp utility, so I filled a wishlist bug report. Earlier this week I already encountered another bug, but this package being Java, I had a good idea on how to fix the bug.

And so I implemented my own wishlist. I’m sure there is room for improvement, as my .deb packaging skills are a bit rusty (a very long time ago I have been in the Debian New Maintainers queue, but by the time they solved the long queue delays, I was too occupied with other things. Yes, this was a long time ago already :). Anyway, Ubuntu’s LaunchPad has a nice feature, called the Personal Package Archives. This service will, after I have finished hacking on the packaging specs in the famous debian/ folder and tested the .debs build from it, will rebuild it and put the resulting package up for download.

Conclusion: a perfect opportunity to finally gives this a try. The learning curve was surprisingly shallow, and the result can be seen in my personal package archive:

Now, you can easily imagine that I will soon work on packaging stuff I did in the past too, such as update libcdk-java and now that OpenJDK in main can run Jmol reasonably, finally package Jmol for main. I just hope I remember my Alioth account, so that I can properly contribute to the debichem project.

Getting back to running scomp on the CML scheme, it works with one minor problem:

$ scomp -src . -d .  cml.xsd
/home/egonw/tmp/cml/cml.xsd:10098:9: warning: p-props-correct.2.2: maxOccurs must be greater than or equal to 1.
Time to build schema type system: 1.792 seconds
Time to generate code: 3.297 seconds
Time to compile code: 9.658 seconds

The problem is reflected by line 10098 which goes like:

<xsd:sequence minOccurs="0" maxOccurs="0">

which can be traced down to line 23 in schema2/trunk/elements/tableHeaderCell.xsd. I filled a bug report about this.

With the upcoming Bioclipse2 beta (scheduled next Friday), all you need to install on top of the Bioclipse2 core is the new XML feature.

So, when Peter and Henry put their first documents online about the Chemical Markup Language (CML), I was thrilled, even though is actually was still SGML when I encountered it. The work predates the XML recommendation. As I recently blogged , in ‘99 I wrote patches for Jmol and JChemPaint to support CML, which were published as preprint in the Chemical Preprint Server in a paper in 2000 in the Internet Journal of Chemistry. Neither of the two has survived.

Anyway, the Chemistry Development Kit makes heavy use of CML, and Bioclipse supports it too. Now, Bioclipse is based on the Eclipse Rich Client Platform architecture, for which there exist quite a few XML tools in the Web Tools Platform (WTP). Among these, a validation, content assisting XML editor. This means, I get red markings when I make my XML document not-well-formed or invalid. Just a quick recap: well-formedness means that the XML document has a proper syntax: one root node, properly closed tags, quotes around attribute values, etc. Validness, however, means that the document is well-formed, but also hierarchically organized according to some specification.

Enter CML. CML is such a specification, first with DTDs, but after the introduction of XML Namespaces with XML Schema (see There can be only one (namespace)). The WTP can use this XML Schema for validation, and this is of great help learning the CML language. Pressing Ctrl-space in Bioclipse will now show you what allowed content can be added at the current character position.

Yes, Bioclipse can do this now (in SVN, at least). This has been on my wishlist for at least two years now, but never really found the right information. Now, three days ago David wrote about End of Year Cramps in which he describes some of his work on the WTP for autocomplete for XPath queries. He see[s] a brighter future for XML at eclipse over the next year. I hope that those in the eclipse and XML community will help to continue to improve the basic support, so that first class commercial quality applications that leverage this support can continue to be built.

That was enough statement for me to ask in the comments on how to make the WTP XML editor aware of the CML XML Schema. It already picked up XML Schema’s with xsi:schemaLocation, but I needed something to worked without such statements in the XML document itself. David explained that me that I could use the org.eclipse.wst.xml.catalog extension. This was really easy, and commited to Bioclipse SVN as:

<extension
  point="org.eclipse.wst.xml.core.catalogContributions">
  <catalogContribution>
    <uri name="http://www.xml-cml.org/schema"
          uri="schema24/schema.xsd"/>
  </catalogContribution>
</extension>

However, that does not make the WTP XML editor available in the Bioclipse application yet. Not ever in the “Open With”… So, I set up a CML Feature. After a follow up question, it turned out that the CML content type of Bioclipse was already a sub type of the XML type (see ):

<extension
  point="org.eclipse.core.runtime.contentTypes">
  <content-type
    base-type="org.eclipse.core.runtime.xml"
    id="net.bioclipse.contenttypes.cml"
    name="Chemical Markup Language (CML)"
    file-extensions="cml,xml"
    priority="normal">
  </content-type>
</extension>

So, the only remaining problem was to actually get the WTP XML editor as part of the Bioclipse application. The new CML Feature takes care of that (I hope the export and building the update site work too, but that’s yet untested), by important the relevant plugins and features. Last night, however, I ended up with one stacktrace which gave me little clue on which plugin I was still missing.

Therefore, I headed to #eclipse and actually met David of the blog that started this again. He asked nitind to think about it too, and they helped me pin down the issue. This relevant bit of the stacktrace turned out to be:

Caused by: java.lang.IllegalStateException
 at org.eclipse.core.runtime.Platform.getPluginRegistry(Platform.java:774)
 at org.eclipse.wst.common.componentcore.internal.impl.WTPResourceFactoryRegistry$ResourceFactoryRegistryReader.(WTPResourceFactoryRegistry.java:275)
 at org.eclipse.wst.common.componentcore.internal.impl.WTPResourceFactoryRegistry.(WTPResourceFactoryRegistry.java:61)
 at org.eclipse.wst.common.componentcore.internal.impl.WTPResourceFactoryRegistry.(WTPResourceFactoryRegistry.java:55)
 ... 37 more

This refered to this bit of code of Eclipse’ Platform.java:

Bundle compatibility = InternalPlatform.getDefault()
  .getBundle(CompatibilityHelper.PI_RUNTIME_COMPATIBILITY);
  if (compatibility == null)
    throw new IllegalStateException();

So, the plugin I turned to to have missing was org.eclipse.core.runtime.compatibility. Apparently, some parts of the WTP that the XMLEditor is using, still uses Eclipse2.x technology.

This screenshot shows the WTP XMLEditor in action in Bioclipse on a CML file. It shows the document contents with the ‘Design’ tab, which also shows allowed content, as derived from the XML Schema for CML. Also, note that the Outline and Properties view automatically come for free, which allows more detail and navigation of the content.

This screenshot shows the ‘Source’ tab for the same file, where I deliberately changed the value of the @id attribute of the first atom. The value does not validate against the regular expression defined in the CML schema for @id attribute values. It also shows the content assisting in action. At any location in the CML file, I can hit Ctrl-Space, and the editor will show me which content I can add at that location.

This makes Bioclipse a perfect tool to craft CML documents and learn the language.

Autogeneration of web content benefits greatly from well defined input, including data types. MetWare uses XML Schema Data Types for this, as mentioned ealier when I briefly mentioned generation of search pages. That example showed the creation of range input on xsd:integer types. The below screenshot shows the different output for xsd:string (input text box) and xsd:boolean:

Now, this example is not really shocking, but MetWare defines additional types, for example an InChI data type:

<simpleType name="inchi">
  <restriction base="string">
    <pattern value="InChI=1/.*"/>
  </restriction>
</simpleType>

This allows me to tweak the HTML output created by the JSF pages to include microformats to support the Sechemtic userscript (see also doi:10.1186/1471-2105-8-487).

Or, to provide a drop down box, listing the allowed values:

<simpleType name="deviceVendor">
  <restriction base="string">
    <enumeration value="BioCrates"/>
    <enumeration value="Bruecker"/>
  </restriction>
</simpleType>

Note the manual adding of peaks at 10 and 100 m/z to get the real peaks somewhere in the middle instead of on the left and right border of the graph.

Meanwhile, the search page is now autogenerated too, and the types of searches allowed (min, max in the picture) again depends on the XML Scheme data type defined in the MetWare SKOS:

<h:dataTable value="#{metobservCharacterizationMassspectrum.spectralPoints.points}" var="specpoint">
  <h:column>
    <f:facet name="header"><h:outputText value="m/z's"/></f:facet>
    <h:outputText value="#{specpoint.mz}"/>
  </h:column>
  <h:column>
    <f:facet name="header"><h:outputText value="Intensities"/></f:facet>
    <h:outputText value="#{specpoint.intensity}"/>
  </h:column>
</h:dataTable>

The <dataTable> @value points (via the faces-config.xml) to the MetobservCharacterizationMassspectrumBean, which has a getSpectralPoints() method (autocreated from the <skos:Concept> SpectralPoints, which has a convenience method List<SpectralPoint> getPoints().

SpectralPoint in turn has the methods getIntensity() and getMz() also used in the above JSF snippet. For convenience, SpectralPointArray also has two other methods: double[] getIntensities() and double[] getMzs() (which I’ll have to rename to reuse the code for NMR support :).

So, here’s the outcome:

Final note, given the dataType, the MetWare bean also has the logic to convert the data back and forth into a SQL serialization, which may eventually use base64 encoding, but currently looks like 61.0,100.0;62.0,1.1, as defined by the regular expression of the XSD dataType for spectralPointArray.

Then I read about SKOS, Simplified Knowledge Organisation System. Unlike OWL, SKOS is less strict on relations between concepts being marked up. Often these concepts are loosely bound, instead following a strict is_a hierarchy. ArMet is a Metabolomics knowledge system which does not have a strong hierarchy, and SKOS seemed to me to be the most suitable markup candidate. So, I SKOS-ified the ArMet specification, resulting in this rather simple document. The document is SKOS, but has an associated skos2html.xsl XSLT stylesheet, so that Firefox converts it to XHTML on the fly.

An entry looks like:

<skos:Concept rdf:about="GenotypeID">
  <skos:prefLabel>genotypeID</skos:prefLabel>

  <skos:definition>A unique identifier for the genotype.</skos:definition>
  <skos:broader rdf:about="GenotypeProperty"/>
</skos:Concept>

The full SKOS specification allows capturing much of what we want to do, including i18n via the label system, loos hierarchical relations via skos:broader, and the concepts of skos:Collection to aggregate concepts. Where needed, it allows borrowing from other languages. For example, to link concepts from MetWare to the original ArMet specification owl:sameAs can be used.

Now I can validate all Chemical Markup Langauge files I have around, which is very useful for those I use to make sure CDK and Bioclipse is working properly. I just need to make sure I use the http://www.w3.org/2001/XMLSchema-instance namespace, for example as in this example from CDK SVN:

<cml title="Regression tests for valid XML Schema documents for CML 2.3"

  xmlns="http://www.xml-cml.org/schema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.xml-cml.org/schema ../../../io/cml/data/cml23.xsd">

Now, I do have some questions. Firstly, does WTP allow recycling of the XML editor? That is, can I use their validating XML editor in, for example, Bioclipse? Would I just depend on the right plugin jars from WTP, or is it more complicated? Alternatively, since in RCP all is a plugin, can WTP be installed as plugin in Bioclipse directly??

Secondly, does Kubuntu or Debian sid have binary packages for WTP? I think to remember having read something about this, in relation with splitting up the WTP into smaller, more specific plugins. Anyone?