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.0 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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id B7DD8BC6C for ; Wed, 6 Feb 2008 23:56:47 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAIXKqUfAXQInh2dsb2JhbACQLgEBAQgKKYEVlRaGDQ X-IronPort-AV: E=Sophos;i="4.25,314,1199660400"; d="scan'208";a="22318906" Received: from concorde.inria.fr ([192.93.2.39]) by mail4-smtp-sop.national.inria.fr with ESMTP; 06 Feb 2008 23:56:47 +0100 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m16MukfQ010988 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 6 Feb 2008 23:56:47 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAJPJqUdA6bjlkWdsb2JhbACQLgEBAQEHBAQLCBEHgRWVGIYN X-IronPort-AV: E=Sophos;i="4.25,314,1199660400"; d="scan'208";a="8878587" Received: from wr-out-0506.google.com ([64.233.184.229]) by mail3-smtp-sop.national.inria.fr with ESMTP; 06 Feb 2008 23:56:45 +0100 Received: by wr-out-0506.google.com with SMTP id c57so3267381wra.9 for ; Wed, 06 Feb 2008 14:56:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; bh=2DBTywGc7URjRjqXO5E+rSezJOEXjg9lDbhXCpW6XdE=; b=EyaI0NWn53nitMNjNjIX+Yso1rxyXKgnhplxDtKEs5IELsEkCPyqQ+Qwq3W43onijx/+ussG9BUG2zJRvZhHg1MKL3xRuVOT/DgunK8ZeMV+t0KfPHf8Q9NfC+aNypBL3XK2VyHXQuXVh6kp1UAggo8zOorMfY3Fm5/l+3O5Gz8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; b=TVraL6X9U7PLNMwqQ3+znJcG3e5JZQTlmbf3KQ5v+r6c0BM23Ww/itt5iCAr9a3p21WyCCYbeRpXyTMEziSwW2iWWyHmU3orfsncaETmLuqjtsqS4haM2z9qKbVD/wZKS6izNhgItukhbmmbkK2XLP/f0VVash68Um7tDeNCjuE= Received: by 10.114.124.1 with SMTP id w1mr2462888wac.114.1202338603713; Wed, 06 Feb 2008 14:56:43 -0800 (PST) Received: from ?192.168.1.58? ( [85.2.96.197]) by mx.google.com with ESMTPS id h6sm1053446nfh.30.2008.02.06.14.56.42 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Feb 2008 14:56:43 -0800 (PST) Cc: caml-list List Message-Id: From: =?ISO-8859-1?Q?B=FCnzli_Daniel?= To: Alain Frisch In-Reply-To: <47AA2C33.70902@frisch.fr> 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] xmlm and names(paces) Date: Wed, 6 Feb 2008 23:56:46 +0100 References: <998006DB-6778-42F1-B2F4-31CB5E9AA6A2@erratique.ch> <47AA2C33.70902@frisch.fr> X-Mailer: Apple Mail (2.915) Sender: =?ISO-8859-1?Q?Daniel=20B=FCnzli?= X-Miltered: at concorde with ID 47AA3B2E.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bunzli:01 buenzli:01 frisch:01 pxp:01 variants:01 namespaces:01 bindings:01 node:01 xml-schema:01 blown:98 parsed:01 caml-list:01 alain:01 prefixes:01 prefixes:01 Le 6 f=E9vr. 08 =E0 22:52, Alain Frisch a =E9crit : > The problem with expanded names is that it makes it quite tedious to =20= > pattern-match on element/attribute names (uri are long!). Agreed. > Another option is to let the client provide a mapping from uri to =20 > fixed prefixes. (PXP can do that kind of prefix normalization.) In xmlm you can do that yourself on input when you get callbacked and =20= do the reverse translation just before outputing start tags. Of course this means more work for the client, but it =20 makes the basic interface simpler and it allows the client to use variants instead of simply shorter prefixes. > It is also a good idea to be able to parse XML documents that conform > to the XML spec but not the XML Namespaces spec. But don't you automatically get that ? A document that has no xmlns namespace declarations and no prefixes if =20= parsed according to the xmlns spec will result in names with empty =20 namespace names. The other problem I see is if there are external prefix declarations, =20= but for that, as I did for external entity references, I have a =20 callback that allows you to bind an undeclared prefix to an uri. > What about something like that: > > type name =3D string * [`N of string * string|`U of string * = string|`X] [...] Too heavy weight for my taste. With xmlm I try to give a reasonable =20 default for xml IO, not the full blown complexity. So I think going =20 with qualified names only is ok, the client can transform its own way =20= if it whishes (e.g. uri replacement). > Also, it is necessary to give the client a way to know the namespace =20= > bindings in scope at any node. Some XML languages like XML-Schema =20 > need this information. A possible way to do it is just to keep the =20 > xmlns declarations as regular attributes. I was planning on keeping the xmlns declarations, but I ignored some =20 languages actually *need* this information, what is it used for in xml-=20= schema ? Thanks for the comments, Daniel=