2013/3/27 Asmus Freytag <asm...@ix.netcom.com>: > At the moment, the statement that the existing encoding is actually > implementable is something that must be considered unproven (enough issues > have been pointed out for various elements of the unification already to > allow such a conclusion). > > What we are not getting closer to is a rational understanding of how to > improve this situation. "Random" addition of middle dot characters for some > purpose is just as bad as pretending everything is fine with the status quo.
We are in fact not discussing "random" additions but want to handle correctly use cases that are in fact very frequently needed. For example The Catalan syllable breaker is not a "random" case, it is in fact highly used and needed as part of its standard orthography (and Catalan is not a minor language, we cannot just ignore it). There are very frequent uses of the dots, and hyphens which are too much overloaded in their original ASCII-only encoding. same thing about apostrophes/quotes. This causes enough nightmares when trying to parse text, and it's unbelievable that there's no solution to augment the text with either distinct characters, or some varant selectors, or some other format controls to disambiguate these uses, which is really semantic on essential character properties (which are in Unicode since long, like the general category). The solution based on an upper-layer protocol will not work (for example in filenames, in databases of toponyms, or in archived legal documents whose interpretation should not cause any trouble, including when these documents are converted or exported to many other formats). We are here exactly within the definition of linguistic rules for each language, some of them being highly standardized and which would require a stricter, less ambiguous ebcoding. The time os ASCII only is over, The UCS offers many new unused possibilities, as well as many existing technical solutions, which should not be based just on an heuristic (which will ever break on many cases). Ysers want to get sure that their text will not be misinterpreted, or rendered in an ambiguous or wrong way. Even if the solutions proposed seem "novel" this should not block us. And even a "novel" solution can work in compatibility with the huge existing corpus of texts which will remain ambiguous as they are. The novel encoding solution can perfectly provide a fallback mechanism where it will adopt the old compatibility scheme (similar to ASCII). Of course, nothing will prevent anyone to use characters as they want in "random" cases, even if this breaks all commonly admitted properties and behaviors. But this should be distinguished from frequently used cases which have rules formulated since long in wellknown languages (excepr that now the texts have to live in a environement which is more and more multilingual, for which it's not possible to just infer which lalnguage to select to apply its wellknown rules). We have no other solutions than providing explicit "hints" in the encoded texts (and to forget the time of ASCII-only, except in some technical domains like programming languages and transport/storage protocols which have their own internal syntaxes and which do not qualify relaly as "plain text").