W3C home > Mailing lists > Public > public-qt-comments@w3.org > February 2014

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

From: <bugzilla@jessica.w3.org>
Date: Mon, 10 Feb 2014 14:25:59 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-24308-523-39BfSQueN4@http.www.w3.org/Bugs/Public/>

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

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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:45 UTC