Re: [Caml-list] XML, XSL, eXcetera

[Gerd Stolpmann <info@gerd-stolpmann.de>]

On 2002.07.04 20:43 Alessandro Baretta wrote:
> 
> 
> 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.

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

> 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. 
 
> 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
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------
-------------------
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