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 26861 - parse-xml-fragment-022 should allow error XPST0005
Summary: parse-xml-fragment-022 should allow error XPST0005
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3 & XPath 3 Test Suite (show other bugs)
Version: Working drafts
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: O'Neil Delpratt
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-19 15:17 UTC by Josh Spiegel
Modified: 2014-11-18 23:51 UTC (History)
1 user (show)

See Also:


Attachments

Description Josh Spiegel 2014-09-19 15:17:14 UTC
<test-case name="parse-xml-fragment-022" xmlns="http://www.w3.org/2010/09/qt-fots-catalog">
        <description>parse-xml-fragment test - result is parentless</description>
        <created by="Michael Kay, Saxonica" on="2013-01-07"/>        
        <environment name="empty"/>
        <test><![CDATA[parse-xml-fragment("<a/>")/..]]></test>
        <result>
            <assert-empty/>
        </result>
</test-case>


This test should also allow XPST0005 (During the analysis phase, it is a static error if the static type assigned to an expression other than the expression () or data(()) is empty-sequence()).  

The return type of parse-xml-fragment is document-node()?.
Comment 1 Michael Kay 2014-11-14 09:38:06 UTC
Technically you should create two versions of the test, with dependencies on static type checking being enabled/disabled, and different results for the two cases, rather than simply defining two permitted results.
Comment 2 Josh Spiegel 2014-11-14 15:41:28 UTC
At the very least, there seems to be a strong precedent for allowing XPST0005 in such cases without tagging the test with the static typing feature.  Bug 21620 is one example but there appear to be many cases throughout the test suite.  I think in this case we should keep with the precedent and simply add the alternate result.
Comment 3 Michael Kay 2014-11-14 15:51:02 UTC
The precedent is there because many of the tests were written before we had the ability to define fine-grained dependencies.

Adding an error as a possible result is that it makes it very easy for test failures to go unnoticed, since generating the wrong error code is not something that gets reported as a test failure.
Comment 4 Josh Spiegel 2014-11-18 23:51:39 UTC
Applied fix suggested in Comment 1.