Menu
▾
▴
#37 Additional chained stylesheet tools
The repository now has a basic mechanism for chaining
stylesheets, but there have been other feature requests
for additional, similar facilities more native to 4XSLT.
See:
http://lists.fourthought.com/pipermail/4suite/2002-July/003947.html
http://lists.fourthought.com/pipermail/4suite/2002-July/003949.html
http://lists.fourthought.com/pipermail/4suite/2002-July/003955.html
Also forwarded by Evan Lenz:
From: "Evan Lenz" <elenz@xyzfind.com>
To: <w3c-xsl-wg@w3.org>
Date: Wed, 9 Jan 2002 17:14:39 -0800
Message-ID:
<BNEMICIEADHDDOIKLHNCKEOBFMAA.elenz@xyzfind.com>
Subject: Feature request: xsl:apply-transform
This isn't in our requirements, but I don't know why not.
I don't care about the syntax, but XSLT's modularity
would be greatly
improved (and many user headaches alleviated) by a
mechanism by which sets
of templates (i.e. stylesheet modules) can be
black-boxed and re-used
without worrying about manual delineation via modes, or
name collisions and
xsl:import precedence.
This is not unlike the externalRef feature in RELAX NG.
(For what it's
worth, James recently told me that he also thinks XSLT
needs a mechanism
like this.)
For example:
<xsl:apply-transform href="blackBox.xsl"
select="$tempTree"/>
This instruction simply effects a transformation of
$tempTree using the
blackBox.xsl stylesheet. Once this instruction is
entered, template rules,
named templates, variables, and parameters in the
calling stylesheet are
disregarded. The practical consequence is that users
won't need to worry
about include conflicts and import overrides (hence
"black box"). The "href"
attribute, as with xsl:include and xsl:import, would
*not* be an AVT,
because all templates still must be known statically.
The stylesheet modularity of XSLT might then be
summarized as follows:
xsl:include merges
xsl:import merges and overrides
xsl:apply-transform segments
Unlike evaluate(), dynamic scopes, and many other
things being proposed,
xsl:apply-transform would not alter what is statically
known in the
stylesheet. Instead, it provides a simple means by
which transformations can
be chained as well as re-used for transforming
subtrees, without exiting
XSLT itself.
Users have expressed a desire for this feature in the
past, and I concur
that such a feature is needed. XSLT will never have a
robust modularity
story if users must always hack into other people's
stylesheets in order to
re-use them. XSLT needs modularity to scale.
"Change the modes" isn't a good answer, because you
don't always have
control over other people's code.
"Use multiple transformations" isn't a good answer
either, especially for
client-side transformations. Besides, that would only
be a workaround for a
fraction of the use cases for xsl:apply-transform.
Some past user feedback along these lines:
http://lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0093.html
http://www.biglist.com/lists/xsl-list/archives/200103/msg00161.html
I think the addition of xsl:apply-transform would
represent a pretty
low-cost solution to what is a pretty embarrassing lack
of modularity in
XSLT 1.0.
Logged In: YES
user_id=38966
I did implement an f:chain-to, which tells the processor to
feed the output to another transform. This is not the same
as Evan's xsl:apply-transform feature request, so I'll keep
this open.
Logged In: YES
user_id=38966
Mike Olson's thoughts about alzy imports are also apropos:
http://lists.fourthought.com/pipermail/4suite/2003-February/005104.html