From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id XAA08575; Thu, 4 Jul 2002 23:51:49 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id XAA08868 for ; Thu, 4 Jul 2002 23:51:48 +0200 (MET DST) Received: from moutng1.kundenserver.de (moutng1.kundenserver.de [212.227.126.171]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g64LplP25914 for ; Thu, 4 Jul 2002 23:51:47 +0200 (MET DST) Received: from [212.227.126.160] (helo=mrelayng0.kundenserver.de) by moutng1.kundenserver.de with esmtp (Exim 3.22 #2) id 17QEVu-0004bs-00; Thu, 04 Jul 2002 23:51:46 +0200 Received: from [80.129.100.135] (helo=gate.gerd-stolpmann.de) by mrelayng0.kundenserver.de with asmtp (Exim 3.35 #1) id 17QEVu-0004ti-00; Thu, 04 Jul 2002 23:51:46 +0200 Received: from ice.gerd-stolpmann.de (ice.gerd-stolpmann.de [192.168.0.13]) by gate.gerd-stolpmann.de (Postfix) with ESMTP id B090ACCDD; Thu, 4 Jul 2002 23:51:44 +0200 (CEST) Received: from ice (localhost [127.0.0.1]) by ice.gerd-stolpmann.de (Postfix) with ESMTP id DE0BF1AD7D; Thu, 4 Jul 2002 23:51:43 +0200 (MEST) Date: Thu, 4 Jul 2002 23:51:43 +0200 From: Gerd Stolpmann To: Alessandro Baretta Cc: Ocaml Subject: Re: [Caml-list] XML, XSL, eXcetera Message-ID: <20020704235143.A621@ice.gerd-stolpmann.de> References: <24542c290fd7023473fa0a397374847c@caldo.demon.co.uk> <3D24975C.2020003@baretta.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <3D24975C.2020003@baretta.com>; from alex@baretta.com on Thu, Jul 04, 2002 at 20:43:40 +0200 X-Mailer: Balsa 1.2.4 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On 2002.07.04 20:43 Alessandro Baretta wrote: > > > forsyth@caldo.demon.co.uk wrote: > > http://gnosis.cx/publish/programming/xml_matters_14.html > > discusses an alternative approach to XSLT for XML > processing that might be of interest to > > some on this list. that page has URLs for the original > papers. > > worth a look. > > This seems an interesting approach. XSLT is direct but weak > in its expressive power. What I really want is a "natural" > way to process XML files in O'Caml. IMHO, we need a "100% > pure O'Caml" approach to XML. PXP seems to be the "way to > go", from this standpoint, for DOM models built through C or > C++ libraries would basically be "wrapped" in their glue > code and untouchable from O'Caml, while PXP builds native > O'Caml datastructures. > > The "hard" approach, which anyone can take directly, is to > parse an XML file with PXP and put it through an O'Caml hard > written function to process it. I think the main drawback of > this approach is the need to compile and link an executable > for every "XSLT-equivalent" filter/processor one might want > to create. >>From my point of view the "hard" approach looks more promising than the "soft" approach, because there are a number of ways to simplify the handling of XML within O'Caml. For example, there is already an XPath implementation (showing how simple this is), and if it were better integrated with the rest, including CamlP4 macros, we could as easily match XML trees with XPath expressions as any other structured value (i.e. we would have an "xmlmatch ... with ..." construct). Another possibility would be a Camlp4 macro that creates XML trees from an XML-like notation. If we had such techniques, O'Caml+PXP+XPath+Camlp4 would be the ultimate language to process XML, because it would be the most integrated one. And integration matters. Today many commercial programs are still written in COBOL because of the excellent integration of SQL. (This does not mean that I compare O'Caml with COBOL, but from a mainstream view they are both exotic.) I don't see that you need to compile and link an executable for every filter, because you can call O'Caml as scripting language. That should be fast enough for most "ad-hoc" usages. > A "soft" approach, which I would prefer, would be to > implement an XSLT processor in O'Caml, with the ability to > define "extension functions" on the run, directly in the > XSLT stylesheet, compile them into the processor dynamically > (as is done in the toplevels), and call them upon activation > of the template within which they appear. Programming an XSLT processor would not be very hard, as XSLT is a quite simple language. > Until something like this appears, I might chose to give up > working with XSLT altogether and stick with the "hard" > O'Caml way, but I think the O'Caml community should move in > the "soft" direction. As far as I can see there have been > several partial attempts at XML management in O'Caml, the > most relevant probably being PXP, but there has been no > unifying view or project guiding these efforts. Do you not > think XML has gained enough momentum for us to start an > official "XML/O'Caml" project to define and implement the > *official* O'Caml API for XML and XML-related technologies > such as XPath and XSLT? > > I would be happy to volunteer for such a project, if anyone > else is interested in it, and if the some consensus is > reached among the community on the APIs that the > to-be-formed team should work on. Defining an API is a very complicated piece of work, and I have doubts that a "virtual" team can do it. Nevertheless, I would appreciate if the community came to a consensus. I can imagine that a simple function-oriented interface would be the best choice for a rather large group of programmers, and it would be simple to add such an interface to the existing XML parsers. A number of people would also be (more) happy if there were a common SAX-like interface. (Although there is no parser that supports this now.) Gerd -- ---------------------------------------------------------------------------- Gerd Stolpmann Telefon: +49 6151 997705 (privat) Viktoriastr. 45 64293 Darmstadt EMail: gerd@gerd-stolpmann.de Germany ---------------------------------------------------------------------------- ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners