29221 2015-10-21 16:43:23 +0000 [XSLT30] fn:unparsed-entity-uri and fn:unparsed-entity-public-id mention a second error code but do no define one 2015-10-29 12:42:30 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Last Call drafts PC Windows NT CLOSED FIXED P2 minor --- 1 abel.braaksma mike public-qt-comments oldest_to_newest 123828 0 abel.braaksma 2015-10-21 16:43:23 +0000 The first para under Rules for this pair of functions reads: >Calling the single-argument form of this function has the same effect as >calling the two-argument form with the context item as the second argument, >except that a different error code is used in error situations. However, this "different error code" is not defined. Moreover, the only error code (XTDE1370 and XTDE1380 resp.) are written in such a way that they can only apply to the one-argument version of the functions. I propose to either (a) update the error texts and first paragraph to reflect the new two-argument signatures, or (b) to add the mentioned extra errors, something along those lines: Error for unparsed-entity-uri: <proposal> [ERR XTDE1371] It is a dynamic error if the two-argument form of the unparsed-entity-uri function is called with the root of the tree of the node given in the second argument is not a document node. </proposal> Error for unparsed-entity-public-id: <proposal> [ERR XTDE1381] It is a dynamic error if the two-argument form of the unparsed-entity-public-id function is called with the root of the tree of the node given in the second argument is not a document node. </proposal> 123842 1 mike 2015-10-22 11:03:26 +0000 I propose we use the wording from the element-with-id() function which has similar rules: A dynamic error is raised [XTDE1370/XTDE1380] if $node, or the context item if the second argument is omitted, is a node in a tree whose root is not a document node. The following errors may be raised when $node is omitted: If the context item is absent, dynamic error [err:XPDY0002] If the context item is not a node, type error [err:XPTY0004] This is an incompatible change to the error code from XSLT 2.0, but since 2.0 could not catch errors and the codes were non-normative anyway, this isn't a big deal. Note that XQuery is considering changing the XPDY0002 condition to a static error in cases where it can be detected statically. 123873 2 mike 2015-10-22 22:18:56 +0000 The change was accepted and has been applied.