[
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
> 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>
>
>
|
