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