This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Multiple output types and embedded documentation
- To: xsl-list at mulberrytech dot com
- Subject: Re: Multiple output types and embedded documentation
- From: David Carlisle <davidc at nag dot co dot uk>
- Date: Mon, 3 Jul 2000 11:28:34 +0100 (BST)
- References: <39B19660C174D311BB9000A0C9E01C3F317ECA@corfu.rnib.org.uk>
- Reply-To: xsl-list at mulberrytech dot com
> Kinda neat!
>
> Anone else think this sounds like the best approach yet for the weave
>
> solution?
Note that the original "write in web, tangle to pascal" approach was
designed not only to allow documented "literate" sources, but to avoid
many of the syntactic restrictions of pascal, such as variables needing
to be declared before use.
While the simple sketch I posted just toggles in or out choices like
out_1 you could spec out an input language that differs substantially
from XSL, together with a transform to XSL as required.
This would allow for example:
boolean queries on the options
include this code if this or this or this,
automatic conversion of some if-then-else syntax to xsl:choose
automatic conversion to the verbose parameter passing syntax from
something more friendly,
translation of extension element calls from some generic syntax to the
vendor specific namespace and syntax required.
but beware the further you go along this route the more you are starting
to define a new language. WEB is not pascal-with-comments it is a
different language, the first stage of the compilation of which is to
transform to pascal (or these days, C). Similarly while the example
stylesheet was still recognisably XSL + documentation + oprional XSLish
statements, the smarter the "code extraction" stylesheet gets, the
further the input input language gets from XSL.
David
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list