This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
(a) The test file aspiring-001.xsl is referenced as aspiring001.xsl in the test catalog (The other test files in the same directory are not referenced at all - presumably this is work in progress). (b) On running the test I get Error at char 22 in xsl:value-of/@select on line 73 column 75 of ncname.xsl: FOCH0001: codepoints-to-string(): invalid XML character [x14] It seems that the template rule on line 62 has been called with the input string "41-5A" and that something is wrong with the hex-to-integer conversion. If we look at the function <xsl:function name="f:fromHex" as="xs:integer"> <xsl:param name="in" /> <xsl:variable name="val" select="function($v) { if($v ge 65) then $v - 55 else $v - 48 }" /> <xsl:sequence select="sum(reverse(string-to-codepoints($in)) ! ($val(.) * math:pow(16, position() - 1))) cast as xs:integer" /> </xsl:function> with $in = "41" string-to-codepoints($in) = (52, 49) $val(52) = -4 $val(49) = -6 I can't see the logic here... I would suggest <xsl:function name="f:fromHex" as="xs:integer"> <xsl:param name="in" /> <xsl:sequence select=" if (string-length($in) = 0) then 0 else if (string-length($in) = 1) then string-length(substring-before('012..ef', $in)) else f:fromHex(substring($in,1,1))*16 + f:fromHex(substring($in,2))"/> </xsl:function>
These tests were committed prematurely and comprise a set of externally provided tests that do not necessarily fit in a category. They are part of a larger set and they need some more scrutiny. Though I thought this function was correct, but I'll have a second look.
Looking at the fromHex function again <xsl:function name="f:fromHex" as="xs:integer"> <xsl:param name="in" /> <xsl:variable name="val" select="function($v) { if($v ge 65) then $v - 55 else $v - 48 }" /> <xsl:sequence select="sum(reverse(string-to-codepoints($in)) ! ($val(.) * math:pow(16, position() - 1))) cast as xs:integer" /> </xsl:function> with $in = "41" string-to-codepoints($in) = (52, 49) reverse(string-to-codepoints($in)) = (49, 52) sum(...) = $val(49) * 16^0 + $val(52) * 16^1 $val(52) = 4 $val(49) = 1 so sum(...) = 1 + 4*16 which is indeed correct. So it looks like I misdiagnosed the problem. The trouble generally with more complex tests is that debugging real or imagined test failures can be an awful lot of work. (For example, the test framework for system-property() is so complex that if one test gives the wrong result, isolating the reason can be a nightmare.)
(In reply to Michael Kay from comment #2) > The trouble generally with more complex tests is that debugging real or > imagined test failures can be an awful lot of work. (For example, the test > framework for system-property() is so complex that if one test gives the > wrong result, isolating the reason can be a nightmare.) While I agree, they also showcase the ability of the spec staying solid and yielding processor-independent and equal results for less-than the most trivial or even non-trivial but isolated cases. I created this category for tests that are reported "from the wild", and are often not fit for a single category. Furthermore, implementations failing a more complex test can either decide not to run it, challenge the test, or, if it is a bug in the implementation, fix it :).
Closing with no further action.