Re: XML and mainframes, yet again (was RE: Some comm
From: "Champion, Mike" <Mike.Champion@S...> > I'm out of my depth here, but this argument doesn't smell right to me. I > thought we concluded in the massive Blueberry thread a few months back that > #x85 probably should have been included in the S production in the first > place, and wasn't mainly because of a lack of mainframe expertise among the > members of the original WG. (PLEASE set me straight if there was a better > reason, I don't claim to know much about mainframes myself except that they > generate a good bit of the revenue that pays my salary <grin>). Actually, at the time that XML 1.0 was created, the control characters 80-9F were undefined in Unicode. Actually, I believe they still are (I am writing this away from an internet connection): Unicode only says what control characters they are by default, but a particular application can map them to private semantics. At the time XML was developed, I called for whitespace and separator rules to be determined by a rational basis, rather than ad hocery. I believe there are only two rational bases: either * all visible whitespace should be allowed as sepchars (with the exception of NBSP for obvious reasons--it should be an error) and all new-lining characters should be newlines, or * parsing considerations should rule, in which case only <127 characters should be used (e.g. so that XML in most ASCII family encodings can be parsed without regard to the specific encoding) The XML WG adopted the second, which is not my preferred choice, but at least is rational. The XML 1.1 suggested rules seem a retreat from rationality into lazy committee thinking of piling on special cases. Cheers Rick Jelliffe
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format