4030 2006-12-03 12:38:49 +0000 [F+O] "may not" ambiguity 2007-02-25 23:35:58 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Functions and Operators 1.0 Candidate Recommendation PC Windows XP CLOSED FIXED P2 normal --- 1 mike ashok.malhotra public-qt-comments oldest_to_newest 13060 0 mike 2006-12-03 12:38:49 +0000 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. 13065 1 ashok.malhotra 2006-12-03 15:17:56 +0000 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". 13070 2 davidc 2006-12-04 15:52:43 +0000 (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. 13071 3 mike 2006-12-04 16:01:13 +0000 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 13163 4 ashok.malhotra 2006-12-13 15:47:52 +0000 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." 14122 5 jim.melton 2007-02-25 23:35:58 +0000 Closing bug because commenter has not objected to the resolution posted and more than two weeks have passed.