This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
This applies to test case fn-function-lookup-494 as well.
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.
Thanks for the clarification.