Lists Home |
Date Index |
At 23:57 22/07/2006, Michael Kay wrote:
>Since about 1993 there has never been a window of time in which new
>technologies could be rapidly adopted client-side; it has always been
>necessary to wait a few years until a significant proportion of the
>installed base of browsers supported the technology in question.
I have been following this discussion with a mixture of pessimism and
optimism. I have thought carefully over the last few days and come
exactly to Michael's conclusion. I want to ask whether this list -
in the spirit of SAX and other developments can actually *do*
something about it.
When Henry Rzepa and I set up this list - in 1997 - our personal
agenda was to see XML developed for communal vocabularies that can be
shared between machines and humans. It now has that potential, but
this discussion has shown it hasn't taken place in many disciplines.
If you look back to XML-DEV archives you will see many similar
discussions back any time after 1998 where we were discussing "the
killer app for the web". I confidently predicted - I think in 1999 -
would be that initial killer app.
We have been continually destroyed and undermined by the browser
manufacturers - including Firefox - which have failed to give us any
stability on the client side. We have built many systems including
upgrade" stop them working.
I take CML as an example. CML. CML is just for elementary chemistry
then journals continue using old specific files for chemical information;
"CML is just for elementary chemistry" as stated on this list- is
totally incorrect. CML is designed for cutting edge chemistry. An
example of how we analyze enzyme reactions - and adopted by journals
is shown in
where under "100 Entries"|"M0001" | "Animated Reaction"
you will see a complete set of chemical reactions autogenerated in
SVG. If you have the right browser at the right phase of the moon you
can see the reactions proceeding over many steps - all in SVG - no
list members to use this as an example of XML over the web. However
what we really want is to ship CML, not SVG over the web because then
the client has the semantics. We just can't
The real problem is that we need to provide 1 million lines of Java
code to the "client". We have these million lines - CML is not a toy.
What we do not have is a stable environment to put them in. We cannot
rely on the browsers to provide the environment. (Interestingly we
had a complete working solution in 1995 on all platforms (UNIX,
Windows, MAC) and all browsers (Mosaic, lynx) and it worked.
Installation was trivial (it used chemical/MIME, helper applications,
and .mailrc files). It has tragically been downhill since then).
Note that in some communities - e.g. bioscience - this is not a
problem - XML is routinely transmitted in gigabits and all genomes,
for example, ate in XML. And it is generally not transformed to HTML
for human readers but processed by machines.
Currently we are looking at two solutions
- lightweight services (a la REST, etc.) - we think everything has
to be ultra lightweight - with as little browser as possible
- Eclipse - see http://www.bioclipse.net/. This is free from the
problems of the browser but requires a cultural commitment for the installer.
My question to the list is "Can this list DO something - not talk,
but DO - that will create a technology and culture for increasing
real XML over the web." Can we identify enough existing lightweight
technology that could be combined and promoted to act as a
Those who weren't around in 1998 - when SAX was developed on this
list - might like to know that David Megginson led a communal
activity with 100 participants and the spec was developed in a month.
This project will be harder, but not, I believe, impossible. I
believe all the components are there, that it can be tied to the REST
philosophy. It needs someone to step forward and coordinate the activity.
Unilever Centre for Molecular Sciences Informatics
University of Cambridge,
Lensfield Road, Cambridge CB2 1EW, UK