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