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

[Bug 27340] [xslt 3.0] Named components (section 3.6.3)

From: <bugzilla@jessica.w3.org>
Date: Wed, 26 Nov 2014 16:29:27 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-27340-523-0jwZqbeMmf@http.www.w3.org/Bugs/Public/>

Abel Braaksma <abel.braaksma@xs4all.nl> changed:

           What    |Removed                     |Added
                 CC|                            |abel.braaksma@xs4all.nl

--- Comment #4 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
If xsl:key is a named component that can only be private, it seems to make
sense to remove it from the list of named components, just like other "named
components" (quotes are deliberate), like xsl:decimal-format and
xsl:character-map, that are not considered "real" named components.

Perhaps it is better if we make a clearer distinction here. The term "named
components" seems too general and feels like any named declaration. We
currently have:

Named components:
- xsl:accumulator
- xsl:attribute-set
- xsl:function
- xsl:key
- xsl:mode
- xsl:param
- xsl:template
- xsl:variable

Named declarations, but not components:
- xsl:character-map
- xsl:decimal-format
- xsl:output

Unnamed declarations:
- xsl:import
- xsl:import-schema
- xsl:include
- xsl:namespace-alias
- xsl:preserve-space
- xsl:strip-space

Declarations not categorized as declarations:
- xsl:expose
- xsl:global-context-item
- xsl:use-package

One suggestion I can think of is a term like "exposable components" or
"overridable components". This would deal with the issues with xsl:param (not
overridable, either always private or always public) and xsl:key (not
overridable). It would also make the other named declarations to be named
components, but not overridable (character-map, decimal-format and output).
Unnamed components (including the unnamed mode) are never overridable (but some
have special rules with packages, like strip/preserve-space).

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Wednesday, 26 November 2014 16:29:29 UTC

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