David Carlisle wrote:
I prefer to call, for each "p", a named template acting [...]
why? (If you are not careful you end up trying to implement the xslt
matching process in xslt which is a big job and unlikely to be
efficient)
Well, that's almost what I had in mind. :-) No, seriously: I'm trying to
make the transformation of my "p" elements kind of configurable, by
importing the style sheet which contains the generic "p" template into
application-specific style sheets.
This is why I want to keep the "p" template free of instructions that
are specific to one type of interpretation of the style attributes.
[BTW: Had forgotten the '@' everywhere in my previous post.]
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.
I fear this might all just be a crazy idea... Which way would go to make
XSLT dynamic in the sense of parametrizing transformations like this?
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.
Yves
--~------------------------------------------------------------------
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>
--~--