21882 2013-04-30 19:11:46 +0000 FOTS test case function-literal-494 should raise an error instead of returning result. 2013-05-01 08:21:52 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 3 & XPath 3 Test Suite Working drafts PC Linux CLOSED INVALID P2 normal --- 1 markos_za oneil mike public-qt-comments oldest_to_newest 87042 0 markos_za 2013-04-30 19:11:46 +0000 The string given as argiment to the xs:normalizedString() function does not conform to the facets of xs:normalizedString, and as a result, the test should raise FORG0001, according to http://www.w3.org/TR/xpath-functions-30/#casting-within-branch 87044 1 markos_za 2013-04-30 19:13:12 +0000 This applies to test case fn-function-lookup-494 as well. 87045 2 mike 2013-04-30 20:25:35 +0000 The relevant rules are in F+O section 18.2. To quote: The supplied string is mapped to a typed value of the target type as defined in [XML Schema Part 2: Datatypes Second Edition]. Whitespace normalization is applied as indicated by the whiteSpace facet for the datatype. The resulting whitespace-normalized string must be a valid lexical form for the datatype. The semantics of casting follow the rules of XML Schema validation. I think you have overlooked the rule about whitespace normalization. The whitespace facet for xs:normalizedString is "replace". This means that the first thing casting does is x09, x0A, and x0C by x20; after this replacement the value is within the lexical space of xs:normalizedSpace and casting therefore succeeds. The rules in 18.2 take precedence over those in 18.3.3 by virtue of the fifth paragraph of section 18 which states: "When casting from xs:string or xs:untypedAtomic the semantics in 18.2 Casting from xs:string and xs:untypedAtomic apply, regardless of target type." I am therefore closing this as invalid. 87056 3 markos_za 2013-04-30 23:45:16 +0000 Thanks for the clarification.