This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In the Note in 7.3.1 (concat), it's unclear what the phrase "the result of fn:concat may not be normalized" means. Does it mean that the processor might not normalize the value, or that it must not normalize the value? It's also unclear what the start of the sentence "As mentioned in the note above" is referring to.
The "As mentioned in the note above" refers, in fact, to a sentence in Section 7.1 [String Types]. I suggest we either remove these words or change then to read "As mentioned in [Section 7.1 String Types]". I believe the "may not be normalized" means may or may not be normalized -- in the sense that there is no need to normalize the result. This reads OK to me but if you feel strongly we can change to "may or may not be normalized".
(In reply to comment #1) > I believe the "may not be normalized" means may or may not be normalized -- in > the sense that there is no need to normalize the result. This reads OK to me > but if you feel strongly we can change to "may or may not be normalized". I'm not the original poster, but I think that change would make things more confusing. I think the main confusion arises because it is not clear (either in the spec, or in the comment #1 quoted above whether "normalized" in "may not be normalized" refers to the action of applying the normalization algorithm, or a description of the resulting string being in normal form. The sentence in 7.1 and the later example in section 7.4.1 make clear, Unicode Normalization will _not_ be applied automatically, this has the effect that the result of concat (like any string) may or may not be "normalized" in the sense that it may or may not be in one of the Normal forms. So I'd suggest changing the first sentence of the note in 7.4.1 to say As mentioned in [Section 7.1 String Types] Unicode normalization is not automatically applied to the result of fn:concat.
Yes, I think David is right on all three counts: (a) the ambiguity between the act of normalizing and the state of being normalized (b) the intended meaning that the processor should perform no normalization (c) the resulting outcome, that is the possibility that the result will not be in normal form
On the Dec 12, 2006 telcon the WGs decided to accept David Carlisle's suggestion to change the first sentence in the note in 7.4.1 to read "As mentioned in [Section 7.1 String Types] Unicode normalization is not automatically applied to the result of fn:concat."
Closing bug because commenter has not objected to the resolution posted and more than two weeks have passed.