From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.9 required=5.0 tests=AWL,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 1DC43BC6C for ; Wed, 30 Jan 2008 03:37:59 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAGRxn0fAXQImh2dsb2JhbACQJQEBAQgKKZdDh1Q X-IronPort-AV: E=Sophos;i="4.25,275,1199660400"; d="scan'208";a="6726257" Received: from discorde.inria.fr ([192.93.2.38]) by mail2-smtp-roc.national.inria.fr with ESMTP; 30 Jan 2008 03:37:58 +0100 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m0U2bwEO029374 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 30 Jan 2008 03:37:58 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAGRxn0dIDtybk2dsb2JhbACQJQEBAQEHBAQLCBaXRYdU X-IronPort-AV: E=Sophos;i="4.25,275,1199660400"; d="scan'208";a="6726256" Received: from fg-out-1718.google.com ([72.14.220.155]) by mail2-smtp-roc.national.inria.fr with ESMTP; 30 Jan 2008 03:37:58 +0100 Received: by fg-out-1718.google.com with SMTP id 22so54900fge.25 for ; Tue, 29 Jan 2008 18:37:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; bh=7lExp9N+lzje9ti05W2IFxxdSpbe7CaqrUpdAhwCTZ0=; b=FhglMmcl160SEicdx/UYZ8PVUzEu+1EXo1gzzDzBQH5WrYVZSOUHdQC3uiMGAfaYxiVmGQdMf1FzjHoGtgFY0AHv2UMdSemsNb0DvwjkRrMqBep6xNySJi6idx/SFgQikV5fGv6YPlBIKUWaCC/u70G1cvRQ7VwZLM6IEvQpVik= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; b=rOkg0PnEPuqg5CEx4XZNuWCS7Wqn0BdJ2UJbIWV2LIaKHFY7asLBEwwMvodmq2JpT9hkTHB6K8JSfHptbH37cbxjym2t0iBdBNy2owN2QKzqk+JFBgtBurNHcsRwYNPtLYAoM8qmPAXm4/0+Af/23O9fXCZat3bixtSDfZp+dBM= Received: by 10.78.156.6 with SMTP id d6mr237367hue.22.1201660677783; Tue, 29 Jan 2008 18:37:57 -0800 (PST) Received: from ?192.168.1.58? ( [85.2.108.254]) by mx.google.com with ESMTPS id i7sm516919nfh.18.2008.01.29.18.37.57 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Jan 2008 18:37:57 -0800 (PST) Message-Id: <52FAAA41-5B70-4F87-9F83-B8A96EA48D34@erratique.ch> From: =?ISO-8859-1?Q?B=FCnzli_Daniel?= To: caml-list List In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [Caml-list] [OSR] Suggested topic - XML processing API Date: Wed, 30 Jan 2008 03:37:59 +0100 References: X-Mailer: Apple Mail (2.915) Sender: =?ISO-8859-1?Q?Daniel=20B=FCnzli?= X-Miltered: at discorde with ID 479FE306.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bunzli:01 buenzli:01 wiki:01 parsers:01 datatype:01 parsers:01 parser:01 parser:01 partial:01 abstract:01 abstract:01 signatures:01 parsing:01 parsing:01 caml-list:01 Le 30 janv. 08 =E0 01:54, Jim Miller a =E9crit : > Inspired by the existing recommendation on the cocan wiki for I/O, =20 > I'd like to recommend the development of a standard interface for =20 > XML processing. Currently there are many different implementations =20= > of XML parsers but their interfaces are very different and don't =20 > allow for easy swapping of implementations. There are many approaches to xml parsing (partial implementations, =20 leniency, well-formedness, validity, etc.), to parsing results (tree, =20= custom data structure, stream, namespace support etc.) and to =20 processing (mainly dependent on the parsing result). Xml processing =20 cannot be seen as an abstract datatype with different implementations, =20= there are different ways. As such I'm not sure such an interface is really feasible. Now if you =20= see a common pattern or concrete type signatures that could be changed =20= to make parsers more compatible do not hesitate to communicate them. =20 If it benefits the users of my parser and remains in its philosophy =20 I'll happily implement them. But _you_ have to make concrete proposal, =20= I'm not going to research this. Please do not just initiate a =20 discussion because you like the abstract idea of being able to swap =20 xml parser implementations, make proposals. Best, Daniel