Date:
Tue, 25 Aug 2009 08:53:18 +0200
MIME-Version:
1.0
Content-Transfer-Encoding:
7bit
Content-Type:
text/plain; charset=us-ascii
|
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
|
|
|