This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Mike recently modified this test to include a document constructor. However, this is an XPath test and there is no document constructor in XPath 3.0. <test-case name="functx-fn-number-all" xmlns="http://www.w3.org/2010/09/qt-fots-catalog"> <description/> <created by="Frans Englich" on="2008-05-16"/> <modified by="Michael Kay" on="2017-03-17" change="make construction of document node explicit"/> <environment ref="functx_prices"/> <dependency type="spec" value="XP30+ XQ10+"/> <test><![CDATA[ let $priceDoc := (/) return document{(number( $priceDoc//prod[1]/price), number( $priceDoc//prod[1]/@currency), number('29.99'), number('ABC'), number( () ), $priceDoc// prod/price[number() > 35])}]]></test> <result> <assert-xml><![CDATA[29.99 NaN 29.99 NaN NaN<price currency="USD">69.99</price><price currency="USD">39.99</price>]]></assert-xml> </result> </test-case> Why was the document constructor necessary?
I added document constructors to a number of tests that were producing a sequence of items and then using assert-xml to test against the result of applying "sequence normalization", that is, the first step of XML serialization. There's nothing in the specs of the test system to say that the sequence normalization process is always carried out. In other cases I changed the assertion to avoid the assert-xml, and that seems a better option here.
More specifically, the spec for assert-xml says "The assert-xml assertion succeeds if the result is an XML document that compares deep-equal to the document contained (in XML form) in the assertion." so it shouldn't be used in cases where the result is not an XML document. (We were hitting problems with these tests in Saxon-JS which does not support serialization.) I've changed this test to use different assertions.