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 tests listed below call fn:in-scope-prefixes($element as element()) as xs:string* and pass the result into one of the following functions/constructors which only accept types with quantifier zero or one. fn:string-length($arg as xs:string?) as xs:integer fn:upper-case($arg as xs:string?) as xs:string fn:lower-case($arg as xs:string?) as xs:string fn:string-to-codepoints($arg as xs:string?) as xs:integer* xs:string($arg as xs:anyAtomicType?) as xs:string? fn:substring-before($arg1 as xs:string?, $arg2 as xs:string?) as xs:string fn:substring-after($arg1 as xs:string?, $arg2 as xs:string?) as xs:string fn:substring($sourceString as xs:string?, $startingLoc as xs:double) as xs:string fn:contains($arg1 as xs:string?, $arg2 as xs:string?) as xs:boolean hence can cause a static typing exception. fn-in-scope-prefixes-10 fn-in-scope-prefixes-11 fn-in-scope-prefixes-12 fn-in-scope-prefixes-13 fn-in-scope-prefixes-14 fn-in-scope-prefixes-15 fn-in-scope-prefixes-16 fn-in-scope-prefixes-19 fn-in-scope-prefixes-20
Nick: Thanks for the comment. Changed the quesry to eliminate the static typing issues. Added "[1]" after the end of the element constructor given as argument to "fn-in-scope-prefixes" Thanks, Carmelo
Shouldn't the [1] be outside of the fn-in-scope-prefixes(...) as this is the function we want to ensure we are only getting one xs:string out of?
Nick: Correct. Corrected. Carmelo
Thanks. Apologies for the delay in closing.