Received: from mx0.gmx.net (mx0.gmx.net [213.165.64.100]) by h1439878.stratoserver.net (8.14.2/8.14.2/Debian-2build1) with SMTP id q8BLLbLK026102 for ; Tue, 11 Sep 2012 23:21:38 +0200 Received: (qmail 4786 invoked by alias); 11 Sep 2012 21:21:32 -0000 Delivered-To: GMX delivery to rainer.schoepf@gmx.net Received: (qmail invoked by alias); 11 Sep 2012 21:21:32 -0000 Received: from relay2.uni-heidelberg.de (EHLO relay2.uni-heidelberg.de) [129.206.210.211] by mx0.gmx.net (mx060) with SMTP; 11 Sep 2012 23:21:32 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id q8BLJFdK027228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Sep 2012 23:19:16 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.8/8.13.1) with ESMTP id q8BEL2wn007582; Tue, 11 Sep 2012 23:19:16 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 3033117 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 11 Sep 2012 23:19:16 +0200 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.13.8/8.13.1) with ESMTP id q8BLJF7f003778 for ; Tue, 11 Sep 2012 23:19:15 +0200 Received: from smtp.demon.co.uk (mdfmta010.mxout.tbr.inty.net [91.221.168.51]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id q8BLJ3IT009957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Sep 2012 23:19:06 +0200 Received: from mdfmta010.tbr.inty.net (unknown [127.0.0.1]) by mdfmta010.tbr.inty.net (Postfix) with ESMTP id 4DB106F8106 for ; Tue, 11 Sep 2012 22:19:03 +0100 (BST) Received: from mdfmta010.tbr.inty.net (unknown [127.0.0.1]) by mdfmta010.tbr.inty.net (Postfix) with ESMTP id 348556F80C7 for ; Tue, 11 Sep 2012 22:19:03 +0100 (BST) Received: from palladium.local (unknown [81.149.193.95]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta010.tbr.inty.net (Postfix) with ESMTP for ; Tue, 11 Sep 2012 22:19:02 +0100 (BST) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MDF-HostID: 3 Message-ID: <504FAAC6.8000605@morningstar2.co.uk> Date: Tue, 11 Sep 2012 22:19:02 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Joseph Wright Subject: Managing/tracking module prefixes To: LATEX-L@listserv.uni-heidelberg.de Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-GMX-Antispam: 0 (Sender is in whitelist: joseph.wright@MORNINGSTAR2.CO.UK); Detail=5D7Q89H36p4L00VTXC6D4q0N+AH0PUCnBi0P5cROEGjO+pG7NAH/K+tf9SrVFtpLrKONl 2T9EL4W4U4jgzLbnCcGpk1z/zwmKT/K1fv3lD0=V1; X-Resent-By: Forwarder X-Resent-For: rainer.schoepf@gmx.net X-Resent-To: rainer@rainer-schoepf.de Status: R X-Status: X-Keywords: X-UID: 7148 Hello all, Take up of expl3 as a programming language raises new issues both in the code itself and in the wider structures. One area which deserves attention is namespacing: management of module prefixes (and related information). In LaTeX2e, this is handled in a broadly successful but somewhat ad hoc manner, relying on searching over released material to find what prefixes are in use. As expl3 formalises the idea of using a namespace prefix for each module, it seems appropriate to consider a more formal approach to managing these. Looking outside of the TeX world, it is notable that similar concerns come up for example in the Perl community: http://www.cpan.org/modules/04pause.html#namespace. Clearly, our requirements are different as expl3 code is a subset of (La)TeX code, and so management at the CTAN level is inappropriate. I think we can see namespace management in two parts: - 'Outside LaTeX': having a system available for consultation before any code is written. - 'Inside LaTeX': making module information available from within a TeX run. At this stage, I want to focus on the 'outside' part of the question. There are many approaches that one can imagine, varying from the very simple to the very complex. An approach I'd like to raise here is at the low-tech end of the spectrum. I envisage a simple list of module prefixes with associated information: the module name, developer(s), contact details, web site, bug tracker, etc. This would be available in public (CTAN/LaTeX3 SVN), but updates would rely on a simple process: contacting the team and making a request. This could then be made more 'high tech' in the future if necessary. An 'open' list of prefixes offers advantages, for example begin able to 'reserve' prefixes in advance of code release (for the team) and making clear that some prefixes are 'free for all' (perhaps "tmp" and "foo", for example). At the same time, there will be some issues, for example how to handle conflicts and how to make sure information remains up to date. Clearly, any such approach requires agreement within the expl3 developer community. Thus what I am seeking here is in the first instance feedback on this idea. Does this seem sensible, workable and useful? -- Joseph Wright