This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 29938 - [XSLT30] Suggestion to drop XTDE1370 and XTDE1380 to bring them in line with XDM 3.0
Summary: [XSLT30] Suggestion to drop XTDE1370 and XTDE1380 to bring them in line with ...
Status: RESOLVED WONTFIX
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-10-16 06:21 UTC by Abel Braaksma
Modified: 2016-10-27 16:46 UTC (History)
0 users

See Also:


Attachments

Description Abel Braaksma 2016-10-16 06:21:38 UTC
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).
Comment 1 Michael Kay 2016-10-19 17:35:36 UTC
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.
Comment 2 Abel Braaksma 2016-10-21 02:04:48 UTC
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).
Comment 3 Abel Braaksma 2016-10-21 02:05:35 UTC
Ok, that wasn't entirely clear, in so many words I meant: let's keep the status quo.
Comment 4 Michael Kay 2016-10-27 16:46:40 UTC
The WG decided to take no action.