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