caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Alain Frisch <frisch@clipper.ens.fr>
To: Gerd Stolpmann <info@gerd-stolpmann.de>
Cc: Alessandro Baretta <alex@baretta.com>, Ocaml <caml-list@inria.fr>
Subject: Re: [Caml-list] XML, XSL, eXcetera
Date: Fri, 5 Jul 2002 02:15:27 +0200 (MET DST)	[thread overview]
Message-ID: <Pine.SOL.4.44.0207050123040.29164-100000@clipper.ens.fr> (raw)
In-Reply-To: <20020704235143.A621@ice.gerd-stolpmann.de>

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 (http://xduce.sourceforge.net):
<< 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 (http://www.cduce.org), 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 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


  parent reply	other threads:[~2002-07-05  0:15 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-04  8:45 forsyth
2002-07-04 18:43 ` Alessandro Baretta
2002-07-04 21:51   ` Gerd Stolpmann
2002-07-04 22:43     ` Alessandro Baretta
2002-07-05  8:06       ` Stefano Zacchiroli
2002-07-06 14:15         ` Alessandro Baretta
2002-07-04 22:46     ` Henrik Motakef
2002-07-05  0:15     ` Alain Frisch [this message]
2002-07-05 16:36       ` Claudio Sacerdoti Coen
2002-07-06 14:22         ` Alessandro Baretta
2002-07-08 12:29           ` Claudio Sacerdoti Coen
     [not found] <Pine.LNX.4.21.0207040823410.30756-100000@vestra.bendery.md>
2002-07-04  8:34 ` Alessandro Baretta
  -- strict thread matches above, loose matches on Subject: below --
2002-07-03 22:59 Alessandro Baretta
2002-07-03 23:02 ` Alexander V.Voinov
2002-07-04  0:34   ` Alessandro Baretta
2002-07-04  8:33 ` Stefano Zacchiroli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.SOL.4.44.0207050123040.29164-100000@clipper.ens.fr \
    --to=frisch@clipper.ens.fr \
    --cc=alex@baretta.com \
    --cc=caml-list@inria.fr \
    --cc=info@gerd-stolpmann.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).