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