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 29759 - [QT3TS] fn-parse-json-923, 924
Summary: [QT3TS] fn-parse-json-923, 924
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3 & XPath 3 Test Suite (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows NT
: 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: 2016-07-29 09:20 UTC by Tim Mills
Modified: 2016-07-29 12:57 UTC (History)
1 user (show)

See Also:

Attachments

Description Tim Mills 2016-07-29 09:20:10 UTC 
The expected result   

<assert-eq>'&#xFFFD;'</assert-eq>

is wrong - it should be

<assert-eq>['&#xFFFD;']</assert-eq>

  <test>parse-json('["\u0000"]', map{'escape':false()})</test>
      <result>
         <any-of>
            <assert-eq>'&#xFFFD;'</assert-eq>
            <error code="FOJS0001"/>
         </any-of>
Comment 1 Michael Kay 2016-07-29 10:00:23 UTC 
Actually I think the result is valid, probably by accident, because

['a'] eq 'a'

is true. A better test would be to use deep-equal.

But looking at the tests, I don't see any justification in the expected result FOJS0001. I don't think an error result is conformant for either of these two tests.
Comment 2 Tim Mills 2016-07-29 10:14:55 UTC 
I've no idea where "FOJS0001" came from either.

We were failing the test

['a'] eq 'a'

because our test suite harness deliberately tries to avoid using our implementation to test itself and I hadn't updated it to take account of atomization here.

I'll switch it to assert-deep-eq and remove the FOJS0001.
Comment 3 Tim Mills 2016-07-29 12:57:37 UTC 
Now fixed.