[
Lists Home |
Date Index |
Thread Index
]
Tim Bray wrote:
>
> Alessandro Triglia wrote:
>
> > What fraction of those use cases would be left out, if the
> issue were
> > regarded as a software issue?
>
> None. That is to say, if you have access to software that
> supports both
> the efficient entry and correct display of the whole Unicode
> character
> repertoire, then you don't have any problem at all.
It doesn't have to be the whole Unicode repertoire. Even your proposed
solution addresses only a subset of Unicode characters. So probably most of
the people would be happy if they had a browser and/or an editor that
supported a reasonable subset of Unicode characters, aiding input and
display.
More importantly, the subset of characters each product supports would only
affect that particular product and would have no impact on interoperability,
because character names would not be used in the encodings. Competition
would drive the extent of support provided by each product, so as to make
the users happy.
The increased complexity of a tool supporting display/input in this way
would likely be less than the increased complexity of a tool supporting
UTF-8+names. It would be less because the encoding would still be unique.
Only the handling of the display form of characters would be affected, which
would need to happen anyway. And there would be no possible confusion
between XML entities and encoding-level pseudo-entities, and so on.
What I am saying is that the extent of the changes that a tool must undergo
in order to support UTF-8+names adequately is probably greater than the
effort for implementing input/display aids as a product-specific feature.
There are also important quality-related issues, as Bob mentioned. If all
the use cases are satisfied, as you seem to agree, by enhancing the
software, this is the route I would prefer.
Alessandro
> --
> Cheers, Tim Bray (http://www.tbray.org/ongoing/)
>
>
>
|
