[
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:
http://pubchem.ncbi.nlm.nih.gov/summary/summary.cgi?cid=28309&disopt=DisplayXML
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
http://pubchem.ncbi.nlm.nih.gov/summary/summary.cgi?cid=28309&disopt=DisplayXML
http://foo.org/pubchem2cml.xsl
cmlVersion=2.5
(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:
<clax>
<claxRequest service="XSLT1.0">
<arg role="input"
url="http://pubchem.ncbi.nlm.nih.gov/summary/summary.cgi?cid=28309&disopt=DisplayXML"/>
<arg role="xsl" url="http://foo.org/pubchem2cml.xsl"/>
<arg role="param" name="cmlVersion" value="2.5"/>
</claxRequest>
<claxResponse url="file://usr/pmr/a123.cml"/>
</clax>
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:
<clax>
<claxRequest service="XMLStorage">
<arg role="input" url="file://usr/pmr/a123.cml"/>
</claxRequest>
<claxResponse url="file://foo/pubchem.log"/>
</clax>
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:
<clax>
<claxRequest service="XMLStorage">
<arg role="context" prefix="cml" namespace="http://www.xml-cml.org/schema"/>
<arg role="search" xpath="//cml:molecule[@id='"28309"/>
</claxRequest>
<claxResponse />
<claxResponse url="file://usr/pmr/28309.cml"/>
</clax>
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.
P.
Peter Murray-Rust
Unilever Centre for Molecular Sciences Informatics
University of Cambridge,
Lensfield Road, Cambridge CB2 1EW, UK
+44-1223-763069
|
