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