[Bug 24308] Overriding templates can also be matching templates, but this case has no rules in the spec

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24308

C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cmsmcq@blackmesatech.com

--- Comment #5 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> ---
The WG discussed this during the ftf meeting in Prague.  The behavior described
in comment 4 seems to the WG to be consistent with treating a template with
both @name and @match as two templates, which can be overridden together or
separately.  The spec should say this.

The mention of 'hidden' as a possible value of the visibility attribute on
xsl:expose is incorrect:  it's not allowed on xsl:expose.

The text of section 3.6.3 doesn't say what happens with xsl:apply-imports and
xsl:next-match when module boundaries are crossed.  

We should ban mode="#all" and mode="#unnamed" inside xsl:override (the latter
is already effectively banned, since the unnamed mode is private).

The sentence about mode="#all" is true (modulo the fact that #all will now be
illegal inside override), but is subject to misconstruction owing to its
location; we probably need to explain why we are saying this here, or move it
to another location.

The note at the end of 3.6.3 should specify select="." on the apply-templates
element.

We considered a proposal to simplify the situation by saying that within
templates within xsl:override, any call to xsl:apply-imports works with an
empty import tree. (The initial import tree is not visible across package
boundaries.) 

ACTION:  editor to come back with a proposal on this.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 10 February 2014 14:26:05 UTC