29938 2016-10-16 06:21:38 +0000 [XSLT30] Suggestion to drop XTDE1370 and XTDE1380 to bring them in line with XDM 3.0 2016-10-27 16:46:40 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Candidate Recommendation PC Windows NT RESOLVED WONTFIX P2 normal --- 1 abel.braaksma mike public-qt-comments oldest_to_newest 127807 0 abel.braaksma 2016-10-16 06:21:38 +0000 This bug applies to our description of fn:unparsed-entity-uri and fn:unparsed-entity-public-id. We currently say this for these errors (descr. is the same for both): [ERR XTDE1370] It is a dynamic error 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. We explain these functions in terms of the dm:unparsed-entity-uri and the dm:unparsed-entity-public-id accessors. According to the DM, these accessors return an empty sequence if applied to something other than a document node. Since our functions find the root of the current tree, this root can be a document node, or something else. In the latter case we ought to raise these errors. I propose to drop these errors. I don't see a use for them and I think it is good to be more in line with the DM. Furthermore, less errors is usually better :). We may consider to return the empty sequence (change of signature) or the empty string (with current signatures). I don't see a problem for either, but have a preference for returning the empty sequence (in line with the DM). 127865 1 mike 2016-10-19 17:35:36 +0000 I fail to see the benefit in this change. These are very rarely used functions, and even if this change gave a notable improvement in usability, which I doubt, it would be hard to justify the cost to us of changing the spec, the cost to implementors of changing the implementation, and the cost to users of testing that their code still works. 127890 2 abel.braaksma 2016-10-21 02:04:48 +0000 These are valid points. I don't know how often these are used in practice and I figured it best to bring them in line with other specs (principal of least surprise). But I get your point on effort vs reward (apart from your last point: we'd be dropping an error scenario that wouldn't have run in XSLT 2.0 to begin with, so no backwards compat issues would arise). 127891 3 abel.braaksma 2016-10-21 02:05:35 +0000 Ok, that wasn't entirely clear, in so many words I meant: let's keep the status quo. 127971 4 mike 2016-10-27 16:46:40 +0000 The WG decided to take no action.