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 prose specification for fn:analyze-string says: The function returns an element node whose local name is analyze-string-result. This element and all its descendant elements have the namespace URI http://www.w3.org/2005/xpath-functions. The namespace prefix is ·implementation-dependent·. The children of this element are a sequence of fn:match and fn:non-match elements. This sequence is formed by breaking the $input string into a sequence of strings, returning any substring that matches $pattern as the content of a match element, and any intervening substring as the content of a non-match element. But the schema describes analyze-string-result-type with mixed="true", thus allowing an xsl:analyze-string element to have text node children. I believe this should be mixed="false".
I guess one possible rationale for putting mixed="true" here is that it makes it legitimate to take the atomizing value of the fn:analyze-string element, for example one can do: substring-before(fn:analyze-string, (fn:analyze-string//fn:group[@nr='1'])) to get the text before the first captured group. (Atomizing an element with element-only content is not allowed, for paternalistic reasons.) I don't think that's a strong enough argument; though we might choose here to remain bug-compatible with 3.0.
Decided to leave the schema saying mixed="true", but add a comment explaining the history.
Action A-660-04: Mike to add a note to F&O to explain that the outermost element of fn:analyze string allows mixed content.
The required Note has been added.