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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] CLAX - Client-side functionality

[ Lists Home | Date Index | Thread Index ]

At 06:14 24/07/2006, Elliotte Harold wrote:
>peter murray-rust wrote:
>>This may be true if I want them to process a document and have it 
>>rendered as HTML in the browser's display for sighted humans. But 
>>suppose I want to send them a.xml and b.xsl and expect them to 
>>create a result document c.xml automatically (i.e. without human 
>>cutting and pasting or pressing a "save" button). Can all browsers 
>>supply that functionality?
>I don't know. It would be nice if we could create c.xml and style it 
>with CSS. I'm not sure if any browser supports this, though. I'm not 
>sure how important this is. It sounds like you want a browser to do 
>something other than browse. Could you elaborate on your use case? 
>Certainly creating a file on the client system is way beyond what 
>any browser should enable. I'm not sure if that's what you mean or not.

Thanks very much - this highlights the fundamental issue. Let me make 
the following simplifying assumptions which I hope will clarify what I want.

0 - browsers are not required at any point and it may be helpful if 
we assume that the client environment does not have one.
1 - the client environment is managed by an intelligent human who is 
capable of and willing to following instructions to install a system 
but who wishes to do little or no programming.
2 - the client has access to a range of URLs run by other 
collaborators which offer non-textual XML content ("data" - see 
example URL below).
3 - the client wishes to carry out a number of XML-based operations 
client side to transform or render or edit or aggregate the data in a 
flexible manner. They do not wish to build a monolithic application 
to do this but wish to call services as appropriate. They wish to use 
lightweight services (not WSDL) running client side (e.g. with 
localhost). The client is allowed to run a simple server such as 
Jetty, configured to access localhost.
4 -they may wish to store XML data either temporarily or permanently. 
They would be grateful if CLAX provided a pre-prepared XML-aware 
database system into which they could put XML documents and from 
which they could retrieve them. The normal output from an operation 
is a new document or document set stored on the file system or in the 
database. Ideally the output will be XML but they occasionally have 
to output legacy documents.
5. - they like XPath, XSLT, and probably XQuery. CSS is no use as it 
doesn't create tangible documents and the transformation required are 
more involved than CSS can provide.
6 - they like lightweight approaches and are prepared to glue 
together simple "workflows" or chains of action. They would prefer 
not to use WSDL, XSD, BPEL, UDDI, etc. which they can't get their 
head round. They are prepared to use one or more scripting languages 
(Python, Javascript (not in browser) seem best). Alternatively they 
can use Java. They prefer their main application libraries (which are 
large) to be in Java. They are prepared to wrap C++ in Java or run it 
as CGI services
7 - they would like CLAX to manage the dependencies and installation 
and updates.
8 - ideally CLAX should evolve to the state where it can be installed 
by someone who doesn't understand XML and doesn't want to but can use 
the scripts and applications developed. This could be by building a 
set of bespoke GUIs or HTML forms in a br*ws*r.

Here is a possible example (all the components already exist - this 
is not vapourware).
1 I have a client-side robot which downloads chemical compounds in 
XML from PubChem at the National Institutes for Health (US).  A 
typical example is caffeine:
2 I wish to convert this to CML (file://usr/pmr/a123.cml) and have a 
stylesheet http://foo.org/pubchem2cml.xsl with a param name=cmlVersion
3 I wish to put the result in a local database

As an example, take only on the second and third steps.  I could do 
something like:
java -jar saxon.jar -o file://usr/pmr/a123.cml 
(I am not sure if Saxon resolves URLs but it shows the logic)

However this means I have to know about Saxon, install it, learn its 
commandline, etc. What I would really like would be to get this 
functionality directly from CLAX (which might use Saxon, or Xalan, or 
MSXML or whatever - I don't care.) Assuming we have a CLAX interface 
this might look like:

<claxRequest service="XSLT1.0">
   <arg role="input" 
   <arg role="xsl" url="http://foo.org/pubchem2cml.xsl"/>
   <arg role="param" name="cmlVersion" value="2.5"/>
<claxResponse url="file://usr/pmr/a123.cml"/>

This is a simple request/response API that offers me all the basic 
XSLT functionality I need, without having to install an XSLT processor myself.

In this case, therefore, a CLAX installation should, by default, 
include an XSLT processor and a service honouring the above API. It 
will take a modest amount of work to create it for Saxon in a Java 
environment. But once that is done it requires no further 
maintenance. It therefore makes XSLT available to anyone prepared to 
install CLAX. The request can even be customised for people using 
click and type if required, perhaps even in a br*ws*r.

In more adventurous fashion the data might be stored something like:
<claxRequest service="XMLStorage">
   <arg role="input" url="file://usr/pmr/a123.cml"/>
<claxResponse  url="file://foo/pubchem.log"/>

Here XMLStorage might be configured to provide access to an 
XMLDatabase such as eXist, XMLDB or whatever.  Since the data are in 
CML where molecule has an id attribute set in the XSLT transformation 
we can now retrieve entries with something like:

<claxRequest service="XMLStorage">
   <arg role="context" prefix="cml" namespace="http://www.xml-cml.org/schema"/>
   <arg role="search" xpath="//cml:molecule[@id='"28309"/>
<claxResponse />
<claxResponse url="file://usr/pmr/28309.cml"/>

I hope that these examples show that XML functionality can be 
provided on a client and the details can be largely hidden from the 
user (human or machine). The key requirements are:
- agreement and enthusiasm to do it.
- a design for the environment (it clearly involves having to run 
code, probably in Java)
- a simple means of installing the language required (Java, Python, etc.)
- a design for the configuration of the CLAX components
- a design for the CLAX API
- a set of basic XML-aware operations, configured to run under the CLAX API.

As I said earlier, we intend to explore this and would be delighted 
if there were others who shared the vision and were prepared to do 
some hacking. As yet I cannot see any technical reason why it should 
not be "fairly simple" to implement. We are prepared to throw away 
V0.1 if a better approach emerges.


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