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=1.9 required=5.0 tests=AWL,DNS_FROM_SECURITYSAGE, SPF_FAIL 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 9ED6BBBB7 for ; Thu, 23 Oct 2008 01:05:42 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoDAHFM/0jAXQImgWdsb2JhbACTawEBFiKyFoNO X-IronPort-AV: E=Sophos;i="4.33,467,1220220000"; d="scan'208";a="16378821" Received: from discorde.inria.fr ([192.93.2.38]) by mail2-smtp-roc.national.inria.fr with ESMTP; 23 Oct 2008 01:05:41 +0200 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m9MN5fl9009323 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 23 Oct 2008 01:05:41 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUBAMFO/0hQW+UCe2dsb2JhbACTawEBFiIEshKDTg X-IronPort-AV: E=Sophos;i="4.33,467,1220220000"; d="scan'208";a="19062121" Received: from main.gmane.org (HELO ciao.gmane.org) ([80.91.229.2]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/AES256-SHA; 23 Oct 2008 01:05:41 +0200 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ksmlm-0004O2-VK for caml-list@inria.fr; Wed, 22 Oct 2008 23:05:38 +0000 Received: from ks300734.kimsufi.com ([91.121.65.225]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 22 Oct 2008 23:05:38 +0000 Received: from sylvain by ks300734.kimsufi.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 22 Oct 2008 23:05:38 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Sylvain Le Gall Subject: Re: Serialisation of PXP DTDs Date: Wed, 22 Oct 2008 23:05:32 +0000 (UTC) Message-ID: References: <51474.6143.qm@web54606.mail.re2.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ks300734.kimsufi.com User-Agent: slrn/pre0.9.9-102 (Linux) Sender: news X-Miltered: at discorde with ID 48FFB1C5.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; le-gall:01 pxp:01 dtds:01 pxp:01 dtds:01 overlooking:01 stone:98 parsed:01 wrote:01 partial:01 partial:01 marshal:01 marshal:01 primitives:01 binary:02 On 22-10-2008, Dario Teixeira wrote: > Hi, > > I am using PXP to parse the MathML2 DTD. This is a fairly large DTD, > which even on a fast machine takes several seconds to parse. I am > therefore looking at ways to serialise a parsed DTD, in a such a way > that it can be reused by other processes. > > Does PXP already offer primitives for (un)serialising DTDs? (I couldn't > find any). Note that using Marshal is out of the question, because DTDs > are stored as objects, and we all know that objects cannot be serialised > across process boundaries. But are there alternative solutions I'm > overlooking? > > On a more general but related note, I think we should start an OSP > discussion about standardising serialisation methods. The rationale > should be obvious. Myself, I am partial to Sexplib, since it is > reasonably fast, very simple to use, human-readable, and future-proof. > I reckon that bin-prot could also be considered, as long as at some > point the binary format is "set in stone", or at least deserialisers > are always backwards compatible. Any other opinions? > You seem to have already some ideas. The best, before doing any discussion on this topic is to try to implement/benchmark the different solution (at least doing something partial). Sexplib/bin-prot/json/marshal need to be compared on a real example. You seems to need this for a particular task. Could you try to implement on your particular example the different approach and give us some benchmark/ease of use/ease of implement level ? Without this number, I think an OSP discussion is pointless. (but with this number at least on a small example, if your use case is not easy, I think an OSP discussion will be very interesting). Regards, Sylvain Le Gall