6795 2009-04-09 07:16:36 +0000 [FO] ^ should not be allowed by XmlCharIncDash 2018-10-09 00:23:40 +0000 1 1 1 Unclassified XML Schema Datatypes: XSD Part 2 1.0 only All All REOPENED 11248 decided P2 normal REC 5 1 eb2m-mrt mike David_E3 jim.melton pumba.parker2017 public-qt-comments oldest_to_newest 24632 0 eb2m-mrt 2009-04-09 07:16:36 +0000 ^ should not be allowed by XmlCharIncDash Because it is now allowed, "[^a]" can be interpreted as a posCharGroup. charClassExpr -> '[' charGroup ']' -> '[' posCharGroup ']' -> '[' charRange charRange ']' -> '[' XmlCharIncDash XmlCharIncDash ']' -> '[' '^' 'a' ']' 24633 1 mike 2009-04-09 07:28:33 +0000 Personal response: I think this is covered by the prose rule in XML Schema Part 2: "The ^ character is only valid at the beginning of a ·positive character group· if it is part of a ·negative character group·" (and the subsequent note which points out that this rule is needed to disambiguate the grammar). The revision to this text in XSD 1.1 Part 2 describes the rule more clearly: "If the first character in a charGroup is '^', this is taken as indicating that the charGroup starts with a negCharGroup. A posCharGroup can itself start with '^' but only when it appears within a negCharGroup, that is, when the '^' is preceded by another '^'. " Come to think of it, I'm not sure why this needs to be written in English - it feels like it could have been achieved in the BNF. 24635 2 eb2m-mrt 2009-04-09 08:14:03 +0000 (In reply to comment #1) > Personal response: > > I think this is covered by the prose rule in XML Schema Part 2: > > "The ^ character is only valid at the beginning of a ·positive character group· > if it is part of a ·negative character group·" I had no ideas about this sentence. But the rewrite in W3C XML Schema 1.1 makes much more sense. 24716 3 mike 2009-04-14 15:38:55 +0000 The joint WGs agreed today to resolve this as Invalid. If this resolution is acceptable, Murata-san, I would be grateful if you could mark it as CLOSED. Michael Kay 24717 4 eb2m-mrt 2009-04-14 15:48:55 +0000 (In reply to comment #3) > The joint WGs agreed today to resolve this as Invalid. If this resolution is > acceptable, Murata-san, I would be grateful if you could mark it as CLOSED. Well, although I agree that the prose in W3C XML Schema 1.0 is correct, I do not think that it is very understandable. It may be succint but is underspecified for non-native speakers. Is it possible to incorporate that part of 1.1 into 1.0? 24719 5 mike 2009-04-14 16:46:16 +0000 This is now addressing a weakness in XSD 1.0 Part 2, rather than in QT Functions and Operators. We could transfer the bug there if you like. However, I think that with the limited resources available to the XML Schema WG, the chances of this getting fixed in an erratum are small. The Schema WG made a conscious decision to put 1.0 bugs on hold until 1.1 is done, and with every year that passes, the value of "improving" the 1.0 spec becomes less. And there are many things more pressing than this problem - the 1.0 spec might not state the answer very elegantly, but I don't think it's ambiguous. 24721 6 eb2m-mrt 2009-04-14 17:39:57 +0000 (In reply to comment #5) I do not trust extensions from those who do not care defects of old versions. > the 1.0 spec might not state > the answer very elegantly, but I don't think it's ambiguous. IMHO, it's understandable only when you understand the intention already. 24735 7 mike 2009-04-15 09:17:11 +0000 I will reopen this bug and reallocate it to XML Schema 1.0 (assuming the system allows me to do that). 25555 8 David_E3 2009-06-12 15:52:48 +0000 (from the telcon minutes of 2009-06-12) Mike Kay summarized the bug and suggested that the best solution would be to change not just the passage objected to by Murata but all of 1.1's regex appendix into 1.0 This would resolve both this issue and some other outstanding bugs and problems. Some retrofitting will be required. We will NOT change the Unicode baseline for XSD 1.0 -- it will remain Unicode 3.1 We will continue to allow support for new versions of Unicode (1.0 status quo already does) We will re-synch the table of character name to Unicode 3.1 We will rephrase the paragraphs about changes to Unicode since 3.1, to tell the story from the 1.0 pov, not the 1.1 pov. (Editorial) We will scour the text to remove references to the implementaiton option of supporting XML 1.1. RESOLVED: to resolve bug 6795 by adopting Michael Kay's change proposal (take the whole regex appendix into 1.0, modulo minor changes outlined above).