Consuming an entity says: > Otherwise, if the number is zero, if the number is higher than > 0x10FFFF, or if it's one of the surrogate characters (characters in > the range 0xD800 to 0xDFFF), then this is a parse error; return a > character token for the U+FFFD REPLACEMENT CHARACTER character > instead. Preprocessing the input stream says: > Any occurrences of any characters in the ranges U+0001 to U+0008, U > +000E to U+001F, U+007F to U+009F, U+D800 to U+DFFF , U+FDD0 to U > +FDDF, and characters U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, U+2FFFE, U > +2FFFF, U+3FFFE, U+3FFFF, U+4FFFE, U+4FFFF, U+5FFFE, U+5FFFF, U > +6FFFE, U+6FFFF, U+7FFFE, U+7FFFF, U+8FFFE, U+8FFFF, U+9FFFE, U > +9FFFF, U+AFFFE, U+AFFFF, U+BFFFE, U+BFFFF, U+CFFFE, U+CFFFF, U > +DFFFE, U+DFFFF, U+EFFFE, U+EFFFF, U+FFFFE, U+FFFFF, U+10FFFE, and U > +10FFFF are parse errors. (These are all control characters or > permanently undefined Unicode characters.) I suggest making characters that are parse errors in the input stream parse errors also when expanded from an NCR. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/Received on Friday, 14 March 2008 10:49:58 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:13 GMT