Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Re: [Caml-list] XML, XSL, eXcetera
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-07-05 (00:15)
From: Alain Frisch <frisch@c...>
Subject: Re: [Caml-list] XML, XSL, eXcetera
On Thu, 4 Jul 2002, 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).

Are you talking of my XPath implementation ?  It was indeed a very simple
piece of code, but it was completely _naive_, and probably quite
inefficient (and moreover poorly integrated with PXP; it is still on my
TODO list to write an implementation of the document model working
directly on PXP trees; is someone interested in such a thing ?).  An XPath
processor should use several optimizations and not stick to a simple
compositional semantics (for instance: rewrite expressions when possible
to use a single descent on the document; use static knowledge about the
documents, such as their DTD, to drive the queries);  I don't know the
state of the art, but I believe that good processors are far from trivial.
This also holds for XSLT, of course.

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

One of the most interesting feature of XML is the existence of
standardized type systems to describe constraints on documents
(variations around 'regular-tree languages', such as DTD or Schema).
In an application (or transformation) XML types allow:
- to check and enforce static properties of the program (does it produces
documents of the expected type ?  are 'xmlmatch' constructs exhaustive ?
...) (--> statically catch a large class of errors in programs)
- to optimize the evaluation or to design an efficient compilation schema

It would be pity to use a typed language whose type system does not
reflect the rich structure of XML types at all.

Here is the place to mention XDuce (
<< XDuce ("transduce") is a typed programming language that is
specifically designed for processing XML data. >>
XDuce processing is organized around a 'xmlmatch' like construction
(however, patterns are not XPath expressions).

XDuce targets the XML part of applications, and it lacks support for
general programming (non XML data-structures, higher-order functions,
...). One may want to integrate XDuce and OCaml (that is, to design an
extension of OCaml that allows XDuce expressions, while retaining XDuce
typing), but it is quite hard to do so as their type systems do not mix
well (XDuce has no ML-like type inference). For the same reason,
interfacing XDuce and OCaml 'modules' is not trivial.

I can also mention my language CDuce (, which is
(or: will be) an extension of XDuce with higher-order and overloaded
functions, incremental programming, records, precise typing of basic
values (for instance, string types are described by regular expressions),
query-language like features, ...

Well, all this rant to say that ok, (OCaml+PXP+XPath+Camlp4) would be a
quite appealing solution (and I would probably use it !), but calling it
the 'ultimate language to process XML' is an overstatement IMHO.

-- Alain

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: