without seeing an example it's hard to say.
My idea was to define an XML language that would describe the desired
transformation for each p style, and to retrieve the transformation
rules specified as XML from inside the application-specific style sheet
that just imports the module with the unmodified "p" template.
that all sounds reasonable until the last bit where I don't see what a
template matching p is doing for you. If it just matches all p's then
tests the style attribute to call named templates then you would
apparent;y get exactly the same effect, but much more efficiently,
by not having the template match all p and instead having separate
templates that match different styles.
Would you consider it a better idea to dynamically generate an
application-specific style sheet containing classical push style
templates, in my case stuff like match="p[(_at_)style='value1'] ? That would
at least allow me to group adjacent siblings into a common container, I
suppose.
I think the grouping is a separate issue, which is usally best handled
in the template that matches the parent of your p elements.
But if your p template looks like
<xsl:template match="p">
<xsl:choose>
<xsl:when test="@style='a'">
<xsl:call-template name="p-a"/>
</xsl:when>
<xsl:when test="@style='b'">
<xsl:call-template name="p-b"/>
</xsl:when>
Then it's usually a good idea to get rid of the p template and change
<xsl:template name="p-a">
to
<xsl:template match="p[(_at_)style='a']">
as it's less code to write, easier to maintain, and more efficient to
run.
If that isn't what you mean by your general p template then ignore the
comments (and give an example:-)
David
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--