Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#53 Template conflicts resolved wrongly

v6.5
closed
Michael Kay
5
2012-10-08
2002-01-21
Michael Kay
No

When there are two template rules that match a given
node, and they both have the same priority and import
precedence, then with the default error handling Saxon
should report the conflict (as a warning) and then
select the rule that comes last in the stylesheet.
However, if one of the rules is an element-specific
rule (a rule that can only match elements of one type)
and the other is a general rule (a rule that can match
elements of multiple types) then Saxon always chooses
the specific rule, regardless which one comes first.

Reported by Norman Walsh.

Present in Saxon 6.5, 7.0 and all previous releases.

Source code fixed in both code branches (module
net.sf.saxon.Mode).

Discussion

  • Michael Kay
    Michael Kay
    2002-02-20

    Logged In: YES
    user_id=251681

    Cleared in 6.5.1

     
  • Michael Kay
    Michael Kay
    2002-04-30

    Logged In: YES
    user_id=251681

    Fixed in 7.1

     
  • Sean Russell
    Sean Russell
    2003-08-08

    Logged In: YES
    user_id=29438

    What does "Cleared" mean? Is this fixed in the 6.5.x branch?

    I'm seeing, what I believe, is similar incorrect behavior. Given the
    following two templates:

    <xsl:template match='gsk:object[starts-with(@type, "image/")]'>
    ...
    <xsl:template name='image'
    match='gsk:header/gsk:object[starts-with(@type, "image/")]'>

    Saxon 6.5.2 generates the following error:

    Warning! Ambiguous rule match for
    /formDescription[1]/header[1]/object[1]
    Matches both "gsk:header/gsk:object[starts-with(@type, "image/")]"
    on line 900 of
    file:///home/szr7739/Work/FormsTK/trunk/styles/ScreenBuilder_html.xsl
    and "gsk:object[starts-with(@type, "image/")]" on line 896 of
    file:///home/szr7739/Work/FormsTK/trunk/styles/ScreenBuilder_html.xsl

    IIRC, the more specific rule should be the highest priority match.

     
  • Michael Kay
    Michael Kay
    2003-08-10

    Logged In: YES
    user_id=251681

    (Response to serxxx)

    Your problem is unrelated to this bug (which, as the
    followups note, was cleared in 6.5.1 and 7.1). You have two
    templates that both match a node, and the two templates have
    the same import precedence and priority. The fact that one
    of the rules matches a subset of the nodes matched by the
    other (is "more specific", in your terms) is irrelevant -
    this plays no part in the conflict resolution alogorithm
    described in the XSLT specification. You should specify
    explicit priorities for the two template rules to ensure
    that the "more specific" rule is also the higher priority rule.

    (If you want to continue this discussion, please find
    another place to do it, as it is not relevant to this bug
    number).

    Michael Kay