[
Lists Home |
Date Index |
Thread Index
]
At 21:00 21/07/2006, Costello, Roger L. wrote:
>[SUMMARY #1] Why is there little usage of XML on the 'visible Web'?
I agree with the analysis that the primary problem is the lack of
client side functionality and I'm suggesting that we can discuss
whether there is a lightweight but powerful way of providing that.
The following ideas are intended to stimulate *practical*
suggestions, and I hope that this thread can remain focused on that.
The symptoms are easy to state: An XML developer cannot make a
document available to an unknown recipient (human or machine) - the
"client" - and assume it has any tools for processing XML. Typical
examples are:
- I cannot mount an SVG document and assume that the client can view
it. (see, for example,
http://jodi.tamu.edu/Articles/v05/i01/Murray-Rust/ where the SVG used
to work in a majority of browsers and now fails in Firefox).
- I cannot send a client an XML document and an XSLT stylesheet and
expect them to process it without further instructions dependent on
their environment.
I want to explore whether we can create a specification of a
client-side environment which would support a reasonably wide range
of XML applications by default and which could be customised further
by communities.
I shall use the term "CLAX" for "client and XML". Please feel free to
mutilate everything suggested here.
The goal of CLAX would be to provide a specification for
*lightweight* services that would be available to a client for
processing XML. They should be stated in machine- and OS-independent
terms (although there will may be some messy implementation
details). It would be aimed at a community not frightened by
installing software and possibly editing configuration, catalog and
other files.
CLAX could consist of:
- an installer. The installer would manage local location of
services, catalogs, dependencies (cf. maven). It would report on what
services were available at any stage. Hopefully it would be able to
state when upgrades or additions to the services appeared.
- a choice of XML functionality wrapped as lightweight services. My
current list would be XSLT, SVG, Schematron, MathML, XSL-FO, some
local storage based on XQuery (maybe an XMLDatabase). The human
installing the system might omit some of these (e.g. an unsighted
human might omit SVG, other might omit MathML). The installer would
manage dependencies between the components (e.g. how many different
versions of Xerces were absolutely necessary). The services would be
REST-like - based on HTTP POST. In many cases (e.g. SAXON, Xalan) the
services would simply represent the commandline options and the XML
streams. All services would be optional except those required by
other services. In many cases the same service could be provided both
by a remote host and localhost, thus allowing offline working.
- domain-specific services (e.g. for CML: viewers, editors, property
calculators,etc.). We have already wrapped several of these in WSDL
(http://wwmm-svc.ch.cam.ac.uk/wwmm/html/) and are now converting to
simpler approaches. These would be installed in the same way as the
generic XML services above and might call some of them - e.g. a
report writer could call the SVG processor whose output would be
converted to PDF by XSL-FO services.
If we were to do this, and if CLAX (or whatever name it evolves to)
were to generate the same sort of interest as SAX, REST and AJAX,
then we could reasonably ask many communities to prepare CLAX-aware
clients. With Java, for example, we believe this to be reasonably
tractable with Maven, .war delivery, etc. What it needs is an agreed
specification that generates enough acceptance by a fast moving community.
In chemistry we are actively looking at developing some sort of
solution along these lines. It would be extremely useful if this (or
a better) approach could be taken up by a wider community. That would
share the load - especially for the generic XML services. Of course
if this has already been done and I'm unaware of it that would be even better.
I'd be grateful if this thread stays on the practical side
P.
Peter Murray-Rust
Unilever Centre for Molecular Sciences Informatics
University of Cambridge,
Lensfield Road, Cambridge CB2 1EW, UK
+44-1223-763069
|
