OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   CLAX - Client-side functionality

[ 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


Peter Murray-Rust
Unilever Centre for Molecular Sciences Informatics
University of Cambridge,
Lensfield Road,  Cambridge CB2 1EW, UK


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS