[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: CLAX - Client-side functionality
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|