- From: <bugzilla@jessica.w3.org>
- Date: Thu, 18 Nov 2010 19:22:47 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5312
Henry Zongaro <zongaro@ca.ibm.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |zongaro@ca.ibm.com
--- Comment #3 from Henry Zongaro <zongaro@ca.ibm.com> 2010-11-18 19:22:43 UTC ---
At its telecon of 18 November 2010,[1] the XSL WG discussed the status of this
enhancement request.
MK summarized discussion from F2F meeting of 2 November 2010[2]
Discussion of notion of compilation unit, and an import mechanism - similar to,
but not same as, xsl:import/xsl:include.
Overriding only ever occurs by importer itself. Conflicts result in an error.
Looked at functions and named templates to begin.
Looked at visibility of these - a single attribute with four values: abstract,
public and overridable, public and non-overridable, private. Settled on names
"abstract", "public", "final" and "private".
Looked at rules for overriding functions and named templates in terms of
signatures. Decided signatures must be the same.
Open item: Should overriding templates be permitted to add parameters with
default values?
Discussion of overriding and interaction with existing override attribute of
xsl:function. Final conclusion was that current semantics for override would
probably have been better handled by xsl:use-when.
Global variables and parameters. Raised issue of two users importing the same
"package". Do they get the same variables (and functions) or different? If
two packages import the same third package, they can do so with different
settings of global variables.
HZ: Minutes of F2F meeting seem to indicate that point hadn't been settled.
MK: My recollection was that there was more consensus on that than minutes
reflect.
Open item: Will global variables be permitted to have different settings in
different importing units?
Open item: Relationship of separate compilation and schemas is a big open
issue.
DN: I think the issue of being able to selectively import objects from a
package is an important usability question.
No decision on this point.
DN: I don't think we should use the term "compilation unit." Can imagine we
might want to have packages that are not compiled, for instance. Don't want to
imply that the packages are compiled.
JS: It hasn't ever been about compilation for me. There are other things
besides being able to separately compile that are enabled by this facility.
SCA: It is related a lot to modularization and segmenting of code. We don't
have a lot of good terms left.
DN: Should a package namespace be forbidden to be used in importing code,
except for overriding? Might help to avoid mistakes.
DN: Could also introduce scope/visibility for objects in imported stylesheet
modules, not just packages. For backwards compatibility, default scope would
be public.
No decision was made on these last two points.
[1] http://lists.w3.org/Archives/Member/w3c-xsl-wg/2010Nov/0042.html
(Member-only link)
[2] http://www.w3.org/XML/Group/2010/11/xsl-ftf-minutes.xml (Member-only link)
--
Configure bugmail: http://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 Thursday, 18 November 2010 19:22:49 UTC