On Sat, September 3, 2011 10:42 am, Geert Bormans wrote:
I think you made some thinking errors in your contribution
I thought that it wasn't too bad as a simplified way of looking at it, but
unfortunately it did ignore the significance of import precedence when
resolving conflicts.
In every part of the XSLT spec that I can think of (e.g, [1], [2]) the
first step in either conflict resolution or finding the best match is to
compare the alternatives based on their import precedence. For example, a
xsl:template with a high @priority value won't be used if it's imported
into a stylesheet with a xsl:template that matches the same context, even
when that xsl:template has a lower specified or default priority.
(When I do XSLT training, I cover conflict resolution for template rules
fairly early on, and when I cover xsl:import later, I review and expand
upon the conflict resolution rules to add the effect of import
precedence.)
I disagree strongly that "you never really need to use xsl:import. "
In complex XSLTs I use both xsl:import and xsl:include simply to make sure
I don't end up with ambiguous rules (I hate warnings coming from the
execution of my stylesheets),
But both opinions are your respective opinions, and I expect they're both
valid according to your own experiences and preferences.
...
I always thought that if there is an ambiguity between templates,
the processor can just take one at random, not necessarily the last one.
Not random. If the XSLT processor chooses to recover from the error, it
has to use the one that's last in declaration order (last paragraph in
[1]). The complete alternatives are that the XSLT processor may
terminate, silently recover by using the last matching template, or log
the error and recover as well [3]. With Saxon, you can control this from
the command line:
-warnings:silent|recover|fatal Handling of recoverable errors
If you get into the habit of expecting the XSLT processor to silently
recover, it can hinder the portability of your stylesheets because someone
else may use it with a different XSLT processor (or you may use it on
another machine) where the processor asserts its spec-given right to throw
an error and terminate on such conflicts. Even questions from your
users/clients/whatever about receiving a slew of conflict warning messages
can be a problem you don't want.
Regards,
Tony Graham tgraham(_at_)mentea(_dot_)net
Consultant http://www.mentea.net
Mentea 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
XML, XSL FO and XSLT consulting, training and programming
[1] http://www.w3.org/TR/xslt20/#conflict
[2] http://www.w3.org/TR/xslt20/#strip
[3] http://www.w3.org/TR/xslt20/#dt-recoverable-error
--~------------------------------------------------------------------
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>
--~--