Altova Mailing List Archives
>xml-dev Archive Home
>Thread Prev - [SUMMARY #1] Why is there little usage of XML on the 'visible Web'?
>Thread Next - RE: [xml-dev] CLAX - Client-side functionality
CLAX - Client-side functionality
To: "Costello, Roger L." <costello@-----.--->,"XML Developers List" <xml-dev@-----.---.--->
Date: 7/23/2006 7:06:00 PM
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