Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 17:19:51 +0200 Received: by mail.proteosys.com (8.14.3/8.14.3) with ESMTP id n7BFJm7d018825 for ; Tue, 11 Aug 2009 17:19:48 +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 n7BFEW7t006837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Aug 2009 17:14:33 +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 n7BCdJ6j028140; Tue, 11 Aug 2009 17:14:31 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.5) with spool id 292158 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 11 Aug 2009 17:14:31 +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 n7BFEVrS013196 for ; Tue, 11 Aug 2009 17:14:31 +0200 Received: from pluto.open.ac.uk (pluto.open.ac.uk [137.108.145.32]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id n7BFE0MX028968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Aug 2009 17:14:04 +0200 Received: from mulberry.open.ac.uk ([137.108.170.73]) by pluto.open.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1Mat2z-0003XL-4X for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 11 Aug 2009 16:13:57 +0100 Received: from KIELDERCMS1.open.ac.uk ([137.108.140.186]) by mulberry.open.ac.uk ([137.108.170.73]) with mapi; Tue, 11 Aug 2009 16:13:57 +0100 Thread-Topic: xparse Thread-Index: AcoaaJjhLIRFuBDsQU+Q8OJmgmUo2gALFVmA References: <4A7921CF.5020803@morningstar2.co.uk> <4A7A1505.4040604@residenset.net> <4A7AD930.2090106@residenset.net> <8516B615-51AA-4D90-BB7D-A9E122AA0335@gmail.com> <4A804317.6050909@morningstar2.co.uk> <4A80469B.5040305@morningstar2.co.uk> <4A804ED7.4040305@morningstar2.co.uk> <4A812A23.2000808@morningstar2.co.uk> <30090124-F668-4FB3-8F03-5CB615F80D6F@gmail.com> <4A813CE2.7080402@morningstar2.co.uk> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by listserv.uni-heidelberg.de id n7BFEVrS013197 Message-ID: Date: Tue, 11 Aug 2009 16:13:56 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: "J.Fine" Subject: Re: xparse To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: <4A813CE2.7080402@morningstar2.co.uk> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-ProteoSys-SPAM-Score: -6.599 () BAYES_00,RCVD_IN_DNSWL_MED X-Scanned-By: MIMEDefang 2.65 on 213.139.130.197 Return-Path: owner-latex-l@LISTSERV.UNI-HEIDELBERG.DE X-OriginalArrivalTime: 11 Aug 2009 15:19:51.0125 (UTC) FILETIME=[2BD51850:01CA1A97] Status: R X-Status: X-Keywords: X-UID: 5886 Joseph Wright wrote: > J.Fine wrote: > > I want documents that can be readily converted to XML. This is a future > requirement for me. TeX macros is not. > > There are two things going on here: > > 1) How LaTeX3 default input syntax might look. The current LaTeX2e model > is bad for this as it is not that structured. So there is a question of > trying to make things more structured, which in part means better > separation of content from appearance. > > 2) How LaTeX3 then typesets input. > > On (1), then a separate tool may well be the best approach, as you > suggest. However, I think that relates more to LaTeX3 input syntax (as > yet undecided). xparse is more about (2) (although I see that there is > quite a lot of overlap to worry about). > > In some ways, I wonder if this issue is related to something that is > explored in xparse. The "real" version has the experimental concept: > > \DeclareDocumentCommandInterface > \DeclareDocumentCommandImplementation > > with the idea that the ...Interface function sets up the user syntax, > while the ...Implementation one actually contains the code: > > \DeclareDocumentCommandInterface \foo { s o m } { foo-implementation } > \DeclareDocumentCommandImplementation { foo-implementation } 3 {} > > So to translate to XML (or whatever) the \foo part does not change, but > only the foo-implementation part does. In that way, the awkward nature > of the LaTeX user interface (optional arguments, stars, ...) is still > handled by the same code even if the result (in foo-implementaion) is > very different. > > So you could imagine \DeclareDocumentCommand doing these for every > function: > > \cs_new:Npn \DeclareDocumentCommand #1#2#3 { > \DeclareDocumentCommandInterface #1 {#2} > { \token_to_set:N #1 -impementation} > \DeclareDocumentCommandImplementation > { \token_to_set:N #1 -impementation} > { \xparse_get_arg_num:n {#2} } % or some such thing! > {#3} > } > > Writing XML is then a case of changing each implementation, without > changing the input at all. Would this go in the right direction? This is a wonderful example of the point I'm making. One starts with TeX macros, adds more features, satisfies more requirements. And then one suggests programming TeX macros that write XML output. And you find yourself programming a LaTeX-like input syntax to XML translator in TeX macros. This is not something I want to be part of, nor something I'd like to use (even though TeX is Turing complete). It seems that LaTeX3 project will use only TeX macros to solve its problems. This restricts the problems it can solve. I think this restriction prevents the creation of LaTeX3. -- Jonathan The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England & Wales and a charity registered in Scotland (SC 038302).