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
[OSR] Suggested topic - XML processing API
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-01-30 (15:55)
From: tab@s...
Subject: Re: [Caml-list] [OSR] Suggested topic - XML processing API
On Wed, Jan 30, 2008 at 03:37:59AM +0100, Bünzli Daniel wrote:
> Le 30 janv. 08 à 01:54, Jim Miller a écrit :
>> Inspired by the existing recommendation on the cocan wiki for I/O, I'd 
>> like to recommend the development of a standard interface for XML 
>> processing.  Currently there are many different implementations of XML 
>> parsers but their interfaces are very different and don't allow for easy 
>> swapping of implementations.
> There are many approaches to xml parsing (partial implementations, 
> leniency, well-formedness, validity, etc.), to parsing results (tree, 
> custom data structure, stream, namespace support etc.) and to processing 
> (mainly dependent on the parsing result). Xml processing cannot be seen as 
> an abstract datatype with different implementations, there are different 
> ways.
> As such I'm not sure such an interface is really feasible. Now if you see a 
> common pattern or concrete type signatures that could be changed to make 
> parsers more compatible do not hesitate to communicate them. If it benefits 
> the users of my parser and remains in its philosophy I'll happily implement 
> them. But _you_ have to make concrete proposal, I'm not going to research 
> this. Please do not just initiate a discussion because you like the 
> abstract idea of being able to swap xml parser implementations, make 
> proposals.

a do-everything interface is absolutely impossible, but providing a "simple"
library that parse DOM and SAX style to fill _common_ needs, is
relatively "easy".

For people that got specifics needs, there's nothing preventing them to
implement/use a side library without using the common distributed library.

Vincent Hanquez