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 {<code>} 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? -- Joseph Wright