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 AAA09266; Fri, 5 Jul 2002 00:37:20 +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 AAA10023 for ; Fri, 5 Jul 2002 00:37:19 +0200 (MET DST) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from athlon.baretta.com (r-mi214-6a228.tin.it [62.211.4.228]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g64MbHP26736 for ; Fri, 5 Jul 2002 00:37:18 +0200 (MET DST) Received: from baretta.com (localhost.localdomain [127.0.0.1]) by athlon.baretta.com (Postfix) with ESMTP id 31F562724D; Fri, 5 Jul 2002 00:43:43 +0200 (CEST) Message-ID: <3D24CF9E.8010904@baretta.com> Date: Fri, 05 Jul 2002 00:43:42 +0200 From: Alessandro Baretta Organization: Baretta srl -- www.baretta.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: it, en MIME-Version: 1.0 To: Gerd Stolpmann Cc: Ocaml Subject: Re: [Caml-list] XML, XSL, eXcetera References: <24542c290fd7023473fa0a397374847c@caldo.demon.co.uk> <3D24975C.2020003@baretta.com> <20020704235143.A621@ice.gerd-stolpmann.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Gerd Stolpmann wrote: > >>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 see your point. But this is not really the "hard" way I had in mind. This is more like defining a brand new DO'M: the Document O'caml Model, and tightly integrating it into the language with CamlP4. Not a bad idea actually, if we work to implement it. Daniel, what do you think about this? > 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. How would you do that? With a sort of "toplevel server" waiting for connections and dynamically compiling and linking into its environment the code sent to it? Is anything like this already around? >>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. It would take a little effort to keep up with the quite numerous standards. And, besides, we would still have to define a mechanism for accessing the full power of the programming language through XSLT stylesheets. >>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 An event based parser is of paramount importance to implement with O'Caml data communication protocols based on XML. I think such a parser should be included in the O'Caml/XML project I proposed. As I stated in my previous post, all the XML-centric work in O'Caml should converge on a common project. I hope some volunteers will show up eventually. Alex ------------------- 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