Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(6.0.3790.3959);
	 Tue, 25 Aug 2009 09:07:15 +0200
Received: by mail.proteosys.com (8.14.3/8.14.3) with ESMTP id n7P77Elc002994
	for <rainer.schoepf@PROTEOSYS.COM>; Tue, 25 Aug 2009 09:07:15 +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 n7P6rm8J032140
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 25 Aug 2009 08:53:48 +0200
Received: from listserv.uni-heidelberg.de (localhost.localdomain [127.0.0.1])
	by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id n7OM2R2E018349;
	Tue, 25 Aug 2009 08:53:25 +0200
Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.5) with
          spool id 285762 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 25 Aug
          2009 08:53:25 +0200
Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de
          [129.206.100.212]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with
          ESMTP id n7P6rPVj012351 for <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>;
          Tue, 25 Aug 2009 08:53:25 +0200
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10])
          by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id
          n7P6rLEc024127 for <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>; Tue, 25 Aug
          2009 08:53:24 +0200
Received: from morse.mittelbach-online.de (p54A845B0.dip.t-dialin.net
          [84.168.69.176]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP
          (Nemesis) id 0MKsym-1MfpuC3zV7-000lFa; Tue, 25 Aug 2009 08:53:21 +0200
Received: by morse.mittelbach-online.de (Postfix,
          from userid 501) id 1231C6EF8D; Tue, 25 Aug 2009 08:53:18 +0200 (CEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <4A7921CF.5020803@morningstar2.co.uk>
            <4A8EC449.4040509@morningstar2.co.uk>
            <19088.5371.517713.176151@morse.mittelbach-online.de>
            <F935973B-32E8-4FD2-9B02-6F55FCB73674@gmail.com>
            <19090.50621.179277.605279@morse.mittelbach-online.de>
            <09905C33-A148-40E5-A28F-0755ECD618AF@gmail.com>
X-Mailer: VM 7.19 under Emacs 21.3.1
X-Provags-ID: V01U2FsdGVkX18r/GWWz6ebrrDuWWjKJZ7bTRncjHULqJbj0+b
              O5NoJ1IYSjgYOczW2idrIZiJRHkJyG5NlrQb8l5h21LxRkH2x7
              2Hr0DMGQdDSHBKktYQ4yQ==
X-Spam-Whitelist-Provider: <frank@mittelbach-online.de>
Message-ID:  <19091.35422.30263.945137@morse.mittelbach-online.de>
Date:         Tue, 25 Aug 2009 08:53:18 +0200
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Frank Mittelbach <frank.mittelbach@LATEX-PROJECT.ORG>
Subject: Re: xparse
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <09905C33-A148-40E5-A28F-0755ECD618AF@gmail.com>
Precedence: list
List-Help: <http://listserv.uni-heidelberg.de/cgi-bin/wa?LIST=LATEX-L>,
           <mailto:LISTSERV@LISTSERV.UNI-HEIDELBERG.DE?body=INFO%20LATEX-L>
List-Unsubscribe: <mailto:LATEX-L-unsubscribe-request@LISTSERV.UNI-HEIDELBERG.DE>
List-Subscribe: <mailto:LATEX-L-subscribe-request@LISTSERV.UNI-HEIDELBERG.DE>
List-Owner: <mailto:LATEX-L-request@LISTSERV.UNI-HEIDELBERG.DE>
List-Archive: <http://listserv.uni-heidelberg.de/cgi-bin/wa?LIST=LATEX-L>
X-ProteoSys-SPAM-Score: -106.599 () BAYES_00,RCVD_IN_DNSWL_MED,USER_IN_WHITELIST
X-Scanned-By: MIMEDefang 2.65 on 213.139.130.197
Return-Path: owner-latex-l@LISTSERV.UNI-HEIDELBERG.DE
X-OriginalArrivalTime: 25 Aug 2009 07:07:15.0111 (UTC) FILETIME=[ACDBC370:01CA2552]
Status: R
X-Status: 
X-Keywords:                  
X-UID: 6003

Will Robertson writes:
 > 
 > Well, when I think about xparse and the idea of multiple layers -1, I  
 > can't help but feel that xparse takes a fairly limiting approach.
 > 
 > Consider Bill Hammond's example:
 >     \section*[short]{long}
 > to
 >     <section numbered="false">
 >     <shorttitle>short</shortitle>
 >     <sectiontitle>long</sectiontitle>
 >     </section>
 > 
 > There is no way we could do that at present with xparse. We'd need to  
 > assign names to all optional arguments and some sort of mapping  
 > between boolean flags and tag attributes.

I think some of the problem here lies in the fact that you all think of xparse
as a bunch of TeX macros providing a single solution. Don't.

Think of xparse as an abstract concept that identifies a layer -1 language
interface. "Identifies" is the keyword I think.

The translation from layer -1 language to layer 0 language might as well
happen with somethign other than a Tex-based language (or even if it is done
with such an engine it might happen depending on the type of layer -1 language
in totally different ways)

This is why I would think that separating the two is key. There is (and can
be) a single interface to declare a layer 0 command. And for each such command
there is an interface declaration for each layer -1 (but how that interface
decl is done might differ from layer -1 to layer -1).

The xml one could for example consist of xml declarations that define how to
translate 

    <section numbered="false">
    <shorttitle>short</shortitle>
    <sectiontitle>long</sectiontitle>
    </section>

into 

    \UseInstance {sectioning} {section} {#1} {#2} {#3}

and nobody says that this translation has to be done by a TeX-based engine
(though it could - long time ago I have written a restricted sgml interface
and others have done similar things).

The big open question for me is to describe what the language at layer 0
really looks like.

frank