This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I have trouble understanding why the expected test result is correct here. The test is: analyze-string("banana", "(a(n?))") This can be interpreted as: b -- non-match an -- match, group 1: an, group 2: n an -- match, group 1: an, group 2: n a -- match, group 1: a, group 2: <empty> or absent A valid outcome, I think, is the following: <fn:analyze-string-result xmlns:fn="http://www.w3.org/2005/xpath-functions"> <fn:non-match>b</fn:non-match> <fn:match> <fn:group nr="1">an<fn:group nr="2">n</fn:group></fn:group> </fn:match> <fn:match> <fn:group nr="1">an<fn:group nr="2">n</fn:group></fn:group> </fn:match> <fn:match> <fn:group nr="1">a<fn:group nr="2" /></fn:group> </fn:match> </fn:analyze-string-result> This is not the same as the current expected outcome, which assumes that "n" is not part of group 1. I'm unsure whether the spec mandates that an empty group *must* be specified, or *may* be absent. Though I see no harm in doing so, I can't readily find this in the spec.
Same is true for analyzeString-017a: analyze-string("banana", "(b(x?))") Currently expected is: <fn:match> <fn:group nr="1">b</fn:group> <fn:group nr="2" /> </fn:match> <fn:non-match>anana</fn:non-match> But I believe the correct result ought to be: <fn:match> <fn:group nr="1">b<fn:group nr="2" /></fn:group> </fn:match> <fn:non-match>anana</fn:non-match> I.e.: the groups are nested, so should be nested in the result. Otherwise there would be no distinction with an regex such as "(b)(x?)" (which I believe would result in the first result above).
The string value of the XML that results from analyze-string is always the original input string; the function essentially takes the original string and adds markup to show the way in which the regex was (or wasn't) matched. I think the spec makes this clear. Your proposed result doesn't have this property. You say that "the current result assumes that "n" is not part of group 1". That's not the case. The current result is <fn:match><fn:group nr="1">a<fn:group nr="2">n</fn:group></fn:group></fn:match> which shows that the "n" is part of both groups 1 and 2 - the groups are nested.
Oh my, looking again at these tests I think I have either been looking at the wrong version locally, or did some copy/paste errors. With a fresh look and your comment, I wholeheartedly agree. It also makes sense that the nesting takes care of the matched strings belonging to more than one group. I will close with no action.