RE: character encoding assumptions and approaches

> The difference is that those other strings aren't important.  
> They are icing, not cake.  They can be dumbed down to 7-bit 
> ASCII with no loss of functionality.

I think it a little arrogant for someone who can use his own native
tongue when describing his implementation in 7-bit should make that
claim. The fact you can't even get any currency symbols into 7bit ASCII
apart from US $ has been a sore point for many years ;-)

However, coming back to the issue in hand, as I see it, we have two
choices: 
 
We do a proper sound engineering job on this issue. That will involve
some kind of negotiation so wo'n't be quick job to implement, and I feel
whilst we're doing it we should go back and re-engineer the whole
requested record syntax/schema/elementSet/language/charset issue.

Or

We do a quick fix - in which case the option bit with the limited scope
suggested by Ralph seems the best approach. Its quick to implement, it
solves the immediate problem. It isn't perfect and there are
inconsistencies as to what it does and doesn't apply to - but that's the
downside of doing a quick fix.

My feeling is we do the quick fix for now - but we start looking at a
proper re-engineering job in the longer term (at this stage to discuss
or decide whether this is a compSpec 2 or a version 4 thing just muddies
the waters - we need to get the requirements done before we start
looking at how to get it into the standard).

Matthew

Received on Friday, 8 March 2002 05:54:32 UTC