On Jan 30, 2005, at 5:00 PM, Graham wrote:
-Proposal
Add "xml:space attributes appearing on Text constructs or their parents MAY be ignored by processors" to 3.1 Text Constructs.
Currently, the draft says *nothing* about xml:space (unless I'm mis-using the search function). If you read the specification for xml:space (http://www.w3.org/TR/REC-xml/#sec-white-space), all it says is that this is a message from the author to downstream software. So there is nothing anywhere that says anything normative about xml:space. Thus, nobody has any standing, or reasonable grounds for expectation, that inserting an xml:space necessarily causes any downstream behavior. Thus, I'm not sure why this assertion is necessary; and it feels kind of weird.
Is the point here to tell them that if they want to control the formatting, they should damn well use type="HTML" or "XHTML"? If so, maybe we should spin the language around and say that:
When type="TEXT", receiving software has a great deal of freedom in how it chooses to display the content. Thus, publishers who want to exercise formatting control should use the values "HTML" or "XHTML" for the type attribute
Would that do it, Graham?
Replace "Thus, software MAY display it using normal text rendering techniques such as proportional fonts, white-space collapsing, and justification." with "Software displaying this text SHOULD remove white-space at the beginning and end; collapse white-space between words; and disregard line break, tab and other formatting characters." in 3.1.1 (TEXT).
No opinion on this. --Tim
