This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
FW: How is this part of the XSLT specification to be interpreted?
- To: "XSL-List (E-mail)" <XSL-List at mulberrytech dot com>
- Subject: FW: How is this part of the XSLT specification to be interpreted?
- From: Thorbjørn Ravn Andersen <TRA at stibo dot dk>
- Date: Tue, 20 Jun 2000 19:14:13 +0200
- Reply-To: xsl-list at mulberrytech dot com
> Thorbjørn,
>
> I think you make a very good point about allowing
> documentation in XSLT
> stylesheets, and particularly structured documentation within
> templates.
Agreed. Especially since XSLT is a very compact language, it
is very important to be able to provide good documentation.
> It might be that XSLT processors will start providing this as
> an extension
> elements or attributes of some kind, or that it is included
> in XSLT 2.0
> whenever that comes along. Thinking aloud, a possibility
> would be to have
> the 'result-prefix' attribute of xsl:namespace-alias take a
> special value
> ('#ignore') for elements that should not be included in the output.
Is there anybody around here with a voice in w3c, who can
raise this issue to them?
It appears to me that the current 19991116 version of XSLT is
completely frozen and that there is quite some time before
any new updates to the XSLT specifications. Is this notion
generally shared?
> At the moment, though, you could take advantage of the fact
> that top-level
> elements that are not within the XSLT namespace are ignored.
> Given your
> example, you can currently legally do:
>
> <doc:test>Hallo</doc:test>
> <xsl:template match="TOC">
> <rowset>
> <xsl:apply-templates/>
> </rowset>
> </xsl:template>
>
>This will probably be sufficient for most small templates -
>it is the
> larger ones that require more internal documentation.
>
> I hope that helps,
Your suggestion is exactly what Norman Walsh is already
tentatively doing with the DocBook XSL style sheets which
apparently is the best that is possible at the moment without
creating a derived style sheet for actual processing, and
which is what I would like to avoid at all costs, since it
moves the documentation too far away from what it documents.
I believe that with XML-based programs, we have an excellent
opportunity to create languages with all the benefits of
Knuth's Literate Programing paradigm without the traditional
disadvantages, since the programmers are well accustomed to
the notion of converting documents to have another view of
them. Especially since XSLT "feels" to me like a functional
language providing a lot of small building blocks, I think
that the idea of building named "chunks" of programs, which
can then be used at will elsewhere, combined with the notion
that the program is just an embedded part of the
documentation, would prove extremely beneficial here.
Best regards,
Thorbjørn
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list