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 {<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?

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).