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

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

[forsyth]

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.

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

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

[Alessandro Baretta]

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.

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.

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.

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

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

[Gerd Stolpmann]

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

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

[Alessandro Baretta]

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

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

[Stefano Zacchiroli]

On Fri, Jul 05, 2002 at 12:43:42AM +0200, Alessandro Baretta wrote:
> 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?

Sure, it's named "/usr/bin/ocaml" :-)

Try this script:

  #!/usr/bin/ocamlrun /usr/bin/ocaml
  print_endline "Hello, world!"

You can use all toplevel directives so you can also use libraries that
support dynamic loading. BTW, if you want to use a library that doesn't
support dynamic loading you have to use a relinked ocaml interpreter or
you will be in trouble.

Maybe I've misunderstood your question ...

Cheers.

-- 
Stefano Zacchiroli - undergraduate student of CS @ Univ. Bologna, Italy
zack@cs.unibo.it | ICQ# 33538863 | http://www.cs.unibo.it/~zacchiro
"I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!" -- G.Romney
-------------------
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

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

[Alessandro Baretta]

<off_topic>
First of all, let me excuse myself for having been away from 
this discussion for a couple of days, but I could not help 
it. The cause, unfortunately, is a tragedy which hit me 
abruptly.
</off_topic>

Stefano Zacchiroli wrote:
> Sure, it's named "/usr/bin/ocaml" :-)
> 
> Try this script:
> 
>   #!/usr/bin/ocamlrun /usr/bin/ocaml
>   print_endline "Hello, world!"
> 
> You can use all toplevel directives so you can also use libraries that
> support dynamic loading. BTW, if you want to use a library that doesn't
> support dynamic loading you have to use a relinked ocaml interpreter or
> you will be in trouble.
> 
> Maybe I've misunderstood your question ...
> 
> Cheers.
> 

I was thinking about something more specific to XML 
processing. Something like a application/processing server 
to be connected with Apache and the like. Such a process 
would have to listen on a socket for connections from 
clients requesting the processing of <?ocaml ...?> tags or 
of an otherwise specified ocaml expression. I am now 
thinking that maybe this would be overshooting the mark 
here, if we are simply thinking of integrating O'Caml code 
in XSLT stylesheets, where the processor is an O'Caml 
application. In this case, one could conceivably link the 
toplevel into the XSLT processor. As an XSLT template is 
activated, if there is any O'Caml code associated with it, 
the processor could just pass it to the "virtual" toplevel 
within it for immediate excecution.

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

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

[Henrik Motakef]

Gerd Stolpmann <info@gerd-stolpmann.de> writes:

> A number of people would also be (more) happy if there were a
> common SAX-like interface.

I am one of those. XML documents nowadays tend to get really big, and
I certanly don't want to store all of them in an object structure in
RAM just to filter out the stuff I'm interested in.

Then again, I really don't insinst on SAX-compatibility, I'd rather
see an OCaml-stream based interface actually, like an xml_event
Stream.t, where type xml_event = start_element of String |
character_data of string | end_element of String ...

Regarding the more general question of an "OCaml XML standard": I'd
think it would be really usefull. Especially a tight integration
(maybe with serious Camlp4 magic, I've no idea if it would be
possible) would rock hard. Just imagine something like


match node with
  | foo/bar -> do_something ()
  | bla/blub[@mumbo="jumbo"] -> something_else ()
  ...

i.e. matching XML nodes with XPathes.  Who would want to use XSLT over
this? Certainly not me, never mind the Java weenies ;-)

Regards
Henrik

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

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

[Alain Frisch]

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

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

[Claudio Sacerdoti Coen]

 I am sorry to enter the discussion so late, but I am abroad attending
 a conference...

 My opinion is:

 1) We need binding to C implementations of DOM, XSLT, etc. to be able to
    do more bindings. For example, we surely want to make bindings to
    GUIs (see lablgtk) and complex widgets for rendering XML staff are
    based on DOM and related stuff.
    The binding me and Luca Padovani did for gdome2 should be considered a
    refined, complete, elegant and tested library, as the binding to the MathML
    widget. The binding to libxslt is a little toy highly incomplete,
    but I have been using it succesfully in the last few months. Moreover
    libxslt is quite performant and I know of no serious open bug or
    missing feature.
 2) XDuce-like stuff would be great but also not standard. I enjoyed
    reading the papers, but I also want to keep on using also the ugly
    but widespread XSLT.
 3) A 100% ocaml XSLT implementation is also something interesting for
    several reasons. Nevertheless I am pretty sure that it is a
    time-expensive piece of code to write, not at all as simple as it seems.
 4) Camlp4 stuff+PXP+XPath would be convenient in the short period, but
    absolutely non standard as the XDuce solution and without the advantages
    of XDuce. Camlp4 sugar would really be nice once you have a native
    XSLT implementation.

 To sum up, IMHO solutions 1-3 are different and solve different problems.
 4 is not so promising as it seems. Finally it is nice to see some
 interest in this field in the ocaml community.

 						Cheers,
						C.S.C.


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

-- 
----------------------------------------------------------------
Real name: Claudio Sacerdoti Coen
PhD Student in Computer Science at University of Bologna
E-mail: sacerdot@cs.unibo.it
http://caristudenti.cs.unibo.it/~sacerdot
----------------------------------------------------------------
-------------------
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

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

[Alessandro Baretta]

Claudio Sacerdoti Coen wrote:
>  To sum up, IMHO solutions 1-3 are different and solve different problems.
>  4 is not so promising as it seems. Finally it is nice to see some
>  interest in this field in the ocaml community.

I more or less agree with you. I would like to be able to 
process XML documents in the most efficient way possible 
(which implies using O'Caml :-) ), while taking advantage of 
the currently available *standard* technology (XSLT, XPath).


Let me restate my primary request: is anyone interested in 
constituting an XML/O'Caml task force, for the sake of 
defining and implementing the official O'Caml XML processing 
API / tools. I volunteer for it, but I will not take up the 
task by myself.

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

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

[Claudio Sacerdoti Coen]

> Let me restate my primary request: is anyone interested in 
> constituting an XML/O'Caml task force, for the sake of 
> defining and implementing the official O'Caml XML processing 
> API / tools. I volunteer for it, but I will not take up the 
> task by myself.

 The same for the ocaml team at Bologna university. If a project
 starts we could participate in the implementation, but we are not
 willing to take up the task due to lack of time.

-- 
----------------------------------------------------------------
Real name: Claudio Sacerdoti Coen
PhD Student in Computer Science at University of Bologna
E-mail: sacerdot@cs.unibo.it
http://caristudenti.cs.unibo.it/~sacerdot
----------------------------------------------------------------
-------------------
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

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

[Alessandro Baretta]

dmitry grebeniuk wrote:
> On Thu, 4 Jul 2002, Alessandro Baretta wrote:
> 
>   Now I'm working on libxml and libxslt bindings to OCaml.  Are you
> interested in it?
> 
> bye

I am definitely interested in xml and xstl tools for o'caml. 
I wonder, though, if your work is not made redundant by 
gdome2-xslt by Claudio Sacerdoti Coen.

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

[Caml-list] XML, XSL, eXcetera

[Alessandro Baretta]

I have just visited the Hump for XML related resources, but 
cannot make much sense out of them. I need a simple (and 
fast) XSLT processor, with the possibility of calling 
"extension" functions. Basically, I'd like to be able to use 
O'Caml within my XLST templates. Has anyone written such a 
hypothetical O'CaXSL document processor?

Or, equivalently, has anyone written O'Caml bindings for 
such XSLT processors as the Apache Xalan-C++? (And, is 
linking with C++ supported in O'Caml?)

I noticed the is a wrapper for the gdome2-xlst library. I 
don't suppose this would allow me to mix O'Caml code with 
XSLT code, would it?

I wonder if the solution could lie with the Ocaml Server 
Pages project. I reckon I might write a Ocaml Server Page 
script generating an XML file which could subsequently be 
processed without the need of extension functions. Would 
anyone reccomend such a strategy?

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

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

[Alexander V.Voinov]

Hi 

From: Alessandro Baretta <alex@baretta.com>
Subject: [Caml-list] XML, XSL, eXcetera
Date: Thu, 04 Jul 2002 00:59:22 +0200

> (And, is 
> linking with C++ supported in O'Caml?)

In which sense? Through `extern "C"' - of course, yes.
Do you mean a more intelligent FFI to map C++ classes onto
OCaml classes? (like what SWIG does for Python)

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

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

[Alessandro Baretta]

Alexander V.Voinov wrote:
> Hi 
> 
> From: Alessandro Baretta <alex@baretta.com>
> Subject: [Caml-list] XML, XSL, eXcetera
> Date: Thu, 04 Jul 2002 00:59:22 +0200
> 
> 
>>(And, is 
>>linking with C++ supported in O'Caml?)
> 
> 
> In which sense? Through `extern "C"' - of course, yes.
> Do you mean a more intelligent FFI to map C++ classes onto
> OCaml classes? (like what SWIG does for Python)

I knew C++ could be linked as 'extern "C"', but I'm not sure 
this would allow me to use a DOM XML parser, because, as far 
as I can see, this method only allows O'Caml code to call C 
functions compiled within C++ code. I wonder if this is 
enough to exploit such DOM parsers as Xerces of the Apache 
project.

Then again, I just realized gdome2-xslt by Claudio Sacerdoti 
Coen might be all that I really need. I'll download it and 
take a good look at it.

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

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

[Stefano Zacchiroli]

On Thu, Jul 04, 2002 at 12:59:22AM +0200, Alessandro Baretta wrote:
> I noticed the is a wrapper for the gdome2-xlst library. I 
> don't suppose this would allow me to mix O'Caml code with 
> XSLT code, would it?

No, you can't, the interface is minimal and permits you to apply
XSLT-only styleshhets:

   val processStylesheet :
    Gdome.document -> I_gdome_xslt.processed_stylesheet

   val applyStylesheet :
    source: Gdome.document ->
    stylesheet:I_gdome_xslt.processed_stylesheet ->
    params:(string * string) list -> Gdome.document

Cheers.

-- 
Stefano Zacchiroli - undergraduate student of CS @ Univ. Bologna, Italy
zack@cs.unibo.it | ICQ# 33538863 | http://www.cs.unibo.it/~zacchiro
"I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!" -- G.Romney
-------------------
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