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 ]

So what you're looking for is a hollow shell, an application framework 
with which capabilities can be provisioned on the fly, from libraries 
obtained over the net?  Or with less tightly coupled code, a sort of 
desktop metaphor for working with XML? A Web Grazer as it were, since 
you need to ruminate on the data and "chew the cud".

Is there no room in CLAX for visualization and interaction with the user? 

I note with some interest that your examples look like re-coded ANT 
tasks.  A few tweaks to OxygenXML to make it easier to integrate with 
ANT would go a long way toward an implementation.

peter murray-rust wrote:
> 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 
> 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
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>


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

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