- From: <bugzilla@wiggum.w3.org>
- Date: Sun, 15 Oct 2006 11:07:02 +0000
- To: public-qt-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=3821 ------- Comment #3 from boen.robot@gmail.com 2006-10-15 11:07 ------- Oh, and for the use-when attribute. 1. Using the system-property() with it will work if all XSLT 2.0 processors and future XSLT 3.0 processors support all declarations or at least all that can be detected with system-propertyes like xsl:supports-serialization. It will help distinguish the XSLT 2.0 behaviour from the XSLT 1.0 and future XSLT ones. However, if a certain declaration is not supported in an implementation, it becomes impossible to make a cross-processor stylesheet, unless explicitly using system-property('xsl:product-name'). 2. Even if we suppose all XSLT 2.0 processors support all standart declarations and future XSLT 3.0 processors support all of the new ones as well (making point 1 invalid), detecting extension declarations ("user-defined data elements") is still impossible, or at least, I can't think of a way to detect them without a function like element-available() or a new system-property for detecting user-defined data elements. Allowing element-available() to at least detect user-defined data elements would cure this. By the way, personally, I think backdraw compatability is not that much of an issue. MSXML 3.0 (with IE6 and IE7), Transformiix (with Firefox 1.5.0.7 and earlier), Opera 9 and Xalan-C (tested in Dreamwaver 8) already return true() to all supported elements. MSXML 4.0+ and libxslt 1.1.15 don't, but then again, if one aimed for a cross-processor stylesheet, (s)he would probably not rely on only the buggy processors' unstandart behaviour to begin with. In other words, using element-available() to detect standart top-level-elements is probably not used that much (in comparrison to detecting availability of extension top-level-elements anyway).
Received on Sunday, 15 October 2006 11:07:13 UTC