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