Though making expat to switch to iconv seems to be the best long term
solution, we can't rely or even wait for it. Expat doesn't change much
and its developers answer mails with a huge delay (if ever). This is not
criticism (I see expat is not their fulltime), just a matter of fact.
As iconv can't be used as universal mean for all sablotron/expat
encoding transformations, we need another way to handle the encoding
issues. We aren't able to change expat, but what we can is to learn
Sablot to convert charset the same way as expat. XML::Encoding charset
maps were created by expat developers (Clark Cooper) for expat and
XML::Parser. If Sablotron addopts this way of conversion, we get a
robust and general mean for both input and output transformations,
supporting about 15 basic charsets. Other charset maps could be added
easily. On top of it, iconv would provide a lot of additional encodings
for output (as it does now). Compared to the current chaotic state, it
doesn't sound bad to me.
I'm looking forward to hear your suggestions or comments.
Petr
Pavel Storek wrote:
> Hi,
>
> IANAP, but it seems, that we will have to seriously consider doing the
> right thing and stay with iconv for all of the encodings except the few
> supported internally by expat/sablotron. This would obviously mean
> working with expat people to include iconv into expat for input
> conversions and suck only utf from expat to sablotron and at the end use
> iconv again for output translation. This is the only robust and long
> term solution IMHO. The only drawback is the systems, where iconv is not
> available or somehow broken. These would be limited to the internal
> character sets, right?
>
> Now I am ducking to avoid the stones from people who know, what they are
> discussing.
>
--
Petr Cimprich
Ginger Alliance Ltd.
www.gingerall.com
