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