- From: <bugzilla@jessica.w3.org>
- Date: Fri, 01 Aug 2014 10:40:33 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26468 --- Comment #2 from Michael Kay <mike@saxonica.com> --- We further considered that if we take this direction, there's no longer a strong reason for xsl:package to be a separate element; we could just use xsl:stylesheet/xsl:transform distinguished by a package-name attribute. On the other hand, this potentially creates confusion between xsl:use-package and xsl:import, you lose the clarity that only stylesheets can be imported and only packages can be used. Note that an XSLT 2.0 processor is likely to accept <xsl:stylesheet version="3.0" package-name="xxx"> and run it in forwards-compatibility mode, whereas it is likely to reject <xsl:package version="3.0"> so we would get a compatibility advantage by going this way. This seems to make it easier to convert an existing stylesheet to a package, and have it able to work with both 2.0 and 3.0 processors. Consider our xml-to-json stylesheet, we would just have to add a package name. But then what happens if the package contains an xsl:import and the target of the xsl:import is itself a package (ie. has a package-name)? A 2.0 processor would simply ignore the package name - as well as any @visibility attributes. But a 3.0 processor would reject it, as violating the rule that import fails if the target is a package. We think that's OK. We think this can work and we can see advantages but we're aware it's a radical step and we need time to think about it. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 1 August 2014 10:40:35 UTC