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 20645 - [QT3TS] parse-xml-010
Summary: [QT3TS] parse-xml-010
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 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: 2013-01-11 15:38 UTC by Tim Mills
Modified: 2013-01-11 18:04 UTC (History)
1 user (show)

See Also:

Attachments

Description Tim Mills 2013-01-11 15:38:00 UTC 
I think the test should be

        <test><![CDATA[parse-xml("<!DOCTYPE a [<!ELEMENT a (#PCDATA)><!ENTITY foo SYSTEM 'parse-xml/foo.entity'>]><a>&foo;</a>")]]></test>

in

    <test-case name="parse-xml-010">
        <description>parse-xml test - with external entity</description>
        <created by="Michael Kay" on="2013-01-07"/>        
        <environment name="empty"/>
        <test><![CDATA[parse-xml("<!DOCTYPE a [<!ELEMENT a (#PCDATA)><!ENTITY foo SYSTEM 'parse-xml/foo.entity'>]><a>&amp;foo;</a>")]]></test>
        <result>
            <assert-xml><![CDATA[<a><bar>baz</bar></a>]]></assert-xml>
        </result>
    </test-case>

to match the intent of the test.
Comment 1 Michael Kay 2013-01-11 16:06:16 UTC 
I think it depends on whether you run it using an XPath processor or an XQuery processor.

The expression is this:

parse-xml("<!DOCTYPE a [<!ELEMENT a (#PCDATA)><!ENTITY foo SYSTEM 'parse-xml/foo.entity'>]><a>&amp;foo;</a>")

In XQuery, the query processor interprets "&amp;" in the string literal as &, so it passes &foo; to the XML parser.

In XPath, the xpath processor does nothing to the string, so it passes "&amp;foo;" to the XML parser.

Do you agree with that analysis? If so, it looks like we need to split it into different tests for XPath and XQuery. Alternatively, we can construct the XML string using string concatenation and codepoints-to-string().
Comment 2 Tim Mills 2013-01-11 16:44:49 UTC 
> Do you agree with that analysis? 

Yes.  I hadn't spotted that it was only failing for XP30 runs, and not XQ30.
Comment 3 Michael Kay 2013-01-11 18:04:22 UTC 
Fixed by using codepoint-to-string() for the ampersand.