References:  <199910011527.LAA04020@hilbert.math.albany.edu>
Message-ID:  <199910011541.QAA13202@nag.co.uk>
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@URZ.UNI-HEIDELBERG.DE>
In-Reply-To:  <199910011527.LAA04020@hilbert.math.albany.edu>
              (hammond@CSC.ALBANY.EDU)
Date:         Fri, 1 Oct 1999 16:41:33 +0100
From: David Carlisle <davidc@NAG.CO.UK>
Sender: Mailing list for the LaTeX3 project
              <LATEX-L@URZ.UNI-HEIDELBERG.DE>
To: Multiple recipients of list LATEX-L
              <LATEX-L@URZ.UNI-HEIDELBERG.DE>
Subject:      Re: Experimental `template' interface code
Status: R

> How would the use of such templates affect Gurari style
> translation to an sgml like docbook?

not so much the templates themselves, but the separation of user syntax
(xparse) from the internal coding, should make that sort of translation
easier.

Basically you would just need to arrange that the document interface
commands became suitably decorated with hooks for the tex4ht back end.

So for docbook level translations you would probably interface
at the commands defined at the xparse layer.

However one may view templates (some of them at least) as a mechanism
that encodes a certain parameterised formatting capability.
This is basically the level of css properties, XSL Formatting Objects,
and DSSSL flow objects. That is objects like `displayed vertical list'
`paragraph' `page layout' etc. If one was particularly interested in
a combined latex XSl FO system one might want to give a template
interface to the FO functionality, and then build the rest of the latex
system up from that. then for latex typesetting you would use the actual
tex implementation of the templates, but for other uses you might trap
things at the level of the interface to the templates, and trivially
encode that in XSL FO syntax. (All this is entirely speculative)

David