- From: <bugzilla@jessica.w3.org>
- Date: Tue, 26 Jun 2012 16:57:20 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=9734
Florent Georges <fgeorges@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fgeorges@gmail.com
--- Comment #4 from Florent Georges <fgeorges@gmail.com> 2012-06-26 16:57:23 UTC ---
I like the idea to be able to set the initial template from
within the stylesheet, thanks Andrew! I have a few comments:
1/ I see the feature a bit differently than in comment #2...
For me, as soon as the stylesheet defines the default initial
template, then the stylesheet will start processing at a named
template (either the default one, or another one specified
explicitly by the user). Regardless whether the user
supplies an input tree or not.
The best use case I have for this new feature is actually
requiring an input tree: the stylesheet requires an input
tree, but provides several entry points (one of them is the
default, but the user can ask for another entry point).
2/ I really don't like the idea to use just "main" in no
namespace. For compatibility reasons of course, but also
because it does not feel right to use NCName for this purpose.
"xsl:main" sounds good to me (e.g. there is no need to bind a
namespace only to use this, as the XSLT namespace is most
likely already bound to a prefix).
3/ Regarding the previous point, I would prefer anyway to have
xsl:stylesheet/@initial-template to set the name of the
default initial template. If we use the other approach (using
a specific name, "main" or "xsl:main" or whatever), an
importing stylesheet won't be able to override the main entry
point and still call the overridden one. If it can override
the default initial template *name* though, it will be able to
set another entry point and call the overridden one simply
because they won't have the same name anymore.
--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 26 June 2012 16:57:26 UTC