- From: Marcos Caceres <marcosc@opera.com>
- Date: Thu, 7 Jan 2010 15:02:50 +0100
- To: cyril.concolato@telecom-paristech.fr
- Cc: public-webapps <public-webapps@w3.org>
On Thu, Dec 17, 2009 at 1:26 PM, Cyril Concolato <cyril.concolato@enst.fr> wrote: > Given that, I have the following questions/remarks: > > - Why do you define control characters, can't you put their code points in > "forbidden characters"? This would simplify the spec and make it more easy > to understand. Agreed; done. > - Could you rename "forbidden characters" to "ZIP forbidden characters"? > This would clearly indicate in which area they are forbidden and why they > are defined. Agreed; done. > - Why do the definition of P&C "space characters" and "Unicode white space > charactes" differ from the XML "white space" definition? As Robin explained, we expect authors to use Unicode as content. > For "Unicode white space characters", I could understand this difference > since it's only used in the "Rule for Getting Text Content with Normalized > White Space" which first applies XML parsing, DOM3 textContent behavior and > then applies additional P&C-defined behavior. But still, I'm wondering: is > this difference really needed? If yes, can you add a note explaining the > rationale and difference with the basic XML processing. > > For "space characters", why did you add U+000B and U+000C? > > - Ignoring U+000B and U+000C, the "Rule for Getting a Single Attribute > Value" seems to me to be already defined in XML as "Attribute-Value > Normalization"(http://www.w3.org/TR/xml/#AVNormalize). I could understand > that you want a self-contained spec but you should at least indicate that > the behavior is the same as the basic XML processing. > Ok, seems I also need to do a little XML archeology too to write such a note. -- Marcos Caceres http://datadriven.com.au
Received on Thursday, 7 January 2010 14:03:38 UTC