30242 2018-04-02 00:13:18 +0000 [XSLT30] (probably editorial, or nothing) xsl:apply-templates section, error XTTE0510 and other type errors 2018-04-02 10:18:26 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Recommendation PC Windows NT RESOLVED INVALID P2 minor --- 1 abel.online mike public-qt-comments oldest_to_newest 129130 0 abel.online 2018-04-02 00:13:18 +0000 I noticed a few things while going over section 6.3 on Applying Template Rules, which discusses xsl:apply-templates. Most of this text is word-for-word equal to the XSLT 2.0 version. Except that we removed the requirement that the select-expression must select nodes. This is correct, of course, but then we define one error condition: "[ERR XTTE0510] It is a type error if an xsl:apply-templates instruction with no select attribute is evaluated when the context item is not a node. " Which left me wondering: what happens if you do select="foo/bar" but the input sequence is not a node? My guess is that it should raise XPTY0020. Should we mention that? it is a bit strange that an *implicit* child::node() expression raises an entirely different error than an explicit child::node() expression. This is primarily because by mentioning only that one error suggests to me that that's the only case where something can go wrong when the context item is not a node. Furthermore, we aren't very explicit about what the focus is of the select-expression. We talk elsewhere about focus-setting containers, but that is not linked to this section. I know how it is supposed to work, but couldn't verify it. I'm not necessarily saying we miss something here, but the text left me wondering nevertheless. I think I expected something like "The select expression of xsl:apply-templates is evaluated with the same focus as its containing construct.". And/or: "If the context item is not of the required type for the select expression a static or dynamic type error will be raised: XPTY0020". But maybe this is too obvious? 129131 1 mike 2018-04-02 09:41:49 +0000 All of this is covered by existing rules. >if you do select="foo/bar" but the input sequence is not a node? The XPath rules will give you a type error evaluating the path expression.(XPath §3.3.2: "If the context item is a node, an axis step returns a sequence of zero or more nodes; otherwise, a type error is raised [err:XPTY0020]." >It is a bit strange that an *implicit* child::node() expression raises an entirely different error than an explicit child::node() expression. Fixing things in XSLT 2.0 just because they are "strange" is not really on our agenda. >Furthermore, we aren't very explicit about what the focus is of the select-expression. §5.3.3.1 is explicit: "Where the containing element of an XPath expression is an instruction or a literal result element, the initial context item, context position, and context size for the XPath expression are the same as the context item, context position, and context size for the evaluation of the containing instruction or literal result element." 129132 2 abel.online 2018-04-02 10:18:26 +0000 > 5.3.3.1 Maintaining Position: the Focus I knew I read that before, yes indeed, that section contains exactly what I meant. > Fixing things in XSLT 2.0 just because they are "strange" is not really on > our agenda. Did you mean, things of XSLT 2.0 that are also in XSLT 3.0? I didn't mean to fix the 2.0 edition ;). I meant that having XTTE0510 where XDTY0020 would seem the more proper error seems a bit odd. But it is not a bug per se, nothing's broken, just odd ;). Either way, I got lost while finding what I needed and it is all there. I'll close this as INVALID.