|
[XML-DEV Mailing List Archive Home]
[By Thread]
[By Date]
[Recent Entries]
[Reply To This Message]
Re: CLAX - Client-side functionality
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
> 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
>
> -----------------------------------------------------------------
> 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>
>
>
|
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
| RSS 2.0 |
 |
| Atom 0.3 |
 |
| |
Stylus Studio has published XML-DEV in RSS and ATOM formats,
enabling users to easily subcribe to the list from their preferred news reader application.
|
Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website.
they were not included by the author in the initial post. To view the content without the Sponsor Links please
click here.
|
|
Cart
