28764 2015-06-04 20:03:42 +0000 [XSLT30] (editorial) xsl:assert should only ever raise XTMM9001 2015-10-29 09:50:35 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Last Call drafts PC Windows NT CLOSED FIXED P2 normal --- 1 abel.braaksma mike public-qt-comments oldest_to_newest 120718 0 abel.braaksma 2015-06-04 20:03:42 +0000 This bug originated in the mail: https://lists.w3.org/Archives/Member/w3c-xsl-wg/2015May/0012.html (member only). This bug was discussed and its resolution as mentioned in that mail was ACCEPTED by the WG at the 2015-06-04 telcon, minutes: https://lists.w3.org/Archives/Member/w3c-xsl-wg/2015Jun/0011.html (member only). Rationale: Assertions are meant to test pre-conditions and, in line with best-practices from TDD, should have one of two outcomes: either succeed, or fail in a determinate manner, that means that even in light of an error, they should fail with their own predefined error. Note that we currently say in 22.2 (which seems to suggest this): <quote> The expression in the test attribute is evaluated. If the effective boolean value of the result is true, the assertion succeeds, and no further action is taken. If the effective boolean value is false, or if a dynamic error occurs during evaluation of the expression, then the assertion fails. </quote> Resolution: As discussed in the 2015-06-04 telcon and ACCEPTED, if an error occurs during evaluation of a xsl:assert's @test attribute or sequence constructor, this should only ever raise XTMM9001 (or whatever is in the @code attribute). This should be mentioned so in the text of xsl:assert. NOTE: marked editorial after finding out that the original text mildly hints in this direction, though I think we should emphasize that an error in the test-expression is never raised, always cloaked. 120725 1 mike 2015-06-05 13:02:10 +0000 I think this is the status quo, but I will add text to make this more clear.