This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 4030 - [F+O] "may not" ambiguity
Summary: [F+O] "may not" ambiguity
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 1.0 (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Ashok Malhotra
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-12-03 12:38 UTC by Michael Kay
Modified: 2007-02-25 23:35 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2006-12-03 12:38:49 UTC
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.
Comment 1 Ashok Malhotra 2006-12-03 15:17:56 UTC
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". 
Comment 2 David Carlisle 2006-12-04 15:52:43 UTC
(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.


Comment 3 Michael Kay 2006-12-04 16:01:13 UTC
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
Comment 4 Ashok Malhotra 2006-12-13 15:47:52 UTC
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."
Comment 5 Jim Melton 2007-02-25 23:35:58 UTC
Closing bug because commenter has not objected to the resolution posted and more than two weeks have passed.