IDL default encoding for wide characters

The DOM states:

"Note: As of August 1998, the OMG IDL specification included a wstring type.
However, that definition did not meet the interoperability criteria of the
DOM
API since it relied on encoding negotiation to decide the width of a
character."

Actually CORBA 2.2 is ambiguous. At one point it says "However, there is no
default wchar code set. If a server supports interfaces that use wide
character data
but does not specify the wchar code sets that it supports, client-side ORBs
will raise exception INV_OBJREF." In another, the algorithm is specified as
having the following "fallbacks" (default encodings): "fallbacks are UTF-8
(for char data) and UTF-16 (for wchar data)". This contradiction appears to
represent the unresolved outcome a long-running debate (in which I was a
participant) about whether it was reasonable to require ORB vendors to
support a common Unicode encoding (I argued for, on the grounds that the
lack of one breaks interoperability, the issue the DOM creators noted). The
argument against came from Fujitsu, who believe that a large number of
Japanese applications cannot support wide characters of any description
(they use 8-bit oriented encodings like Shift-JIS). However, in my view it
is unreasonable to require that OMG break interoperability simply to
accommodate the limitations of pre-Unicode applications (better to have a
few partially conforming ORBs).

It would be most useful if the DOM group could (a) point out this
contradiction to the ORB revision people in OMG and (b) request that UTF-16
support be *required* of ORBs to guarantee interoperability.

Alex Thomas 
IT Architect 
Dresdner Kleinwort Benson 
20 Fenchurch Street 
London 
EC3P 3DB 
UK 

thomasae@kben.co.uk <mailto:thomasae@kben.co.uk> 
Tel: +44 171 475 9030 
Fax: +44 171 475 9540

Received on Friday, 25 September 1998 11:08:54 UTC