mc@x... (Mike Champion) writes: >No more than any other non-trivial encoding, which gets in to deep >philosophical territory about whether "Ë?" is the same as "oe" or >whether the a Chinese character that looks like and has the same root >meaning as a Kanji character is the "same" character or not. Or >whether the Unicode NEL character is a "standard" newline character >because it is mainly used in those mainframes we like to pretend don't >exit :-) Tim's approach is taking a real, widespread problem and >offering a clean, layered solution -- essentially a character encoding >preprocessor -- rather than changing XML itself. This makes me laugh hysterically, as the original notion of Unicode was to develop a big enough space that all the characters could live in happy co-existence without need for layering in the character space. Unicode itself ran out of room and put in surrogates. Now it seems that we've run out of patience and added yet another layer of processing in the middle. >IMHO, it extends the Unicode encoding layer upwards to >remove a wart in XML, not vice-versa. The wart has remained in XML because the W3C hasn't dared address entities directly, and instead we end up with side-paths like XInclude and now this bizarre boil. They create new problems while thinking the old ones are gone. It reminds me of spackling holes in walls with toothpaste. >Anyway, I think this is a great idea, and I >congratulate Tim for working it out and moving it >forward. I think this is an idea with so many problems that it's hard to sort out which are catastrophic and which are merely details. Perhaps I should just capitulate, since the "solutions" for XML's acknowledged problems seem to get worse and worse and worse and worse.
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