RE: ISSUE-10: [API] Should we be using well known types from other domains, such as DOMString?

I am still thinking of what Rhys said in the audio-conference about the
nature of DOMString and its "local" purpose.

The fact is that the DOM working group needed UTF-16 characters and, in
order to support it without all the implicit encoding negotiation of
wstring, defined it as a sequence of short. Thus, any IDL compiler will
generate a DOMString as a sequence of short for any target programming
language, and the implementations will have to know that each short is a
UTF-16 char. I do not see what it has to see with what Rhys commented.

 

This might be the same in our case.

 

Or another option would be to define how IDL string maps to the
appropriate data type in the different target programming languages.
This is, we would define an IDL and mandate on how to map each type. Our
normative mapping can be, by default, OMG IDL normative mappings plus
some exceptions: for instance, string to java.lang.String in an IDL to
Java mapping. Of course, IDL to Java is an example and we would have to
do the same for all the target languages that we want to cover (PHP,
C++, .NET, ...).

 

So, as a summary:

 

-          Option 1: A string is a sequence of 16-bit chars (short) and
implementations must know that each char is a UTF-16.

o        Pros: It is clear to any implementation that strings are UTF-16
without any possible encoding negotiation.

o        Cons: More programming needed as it is the programmer who knows
how to handle the strings. And the programming tasks are really "dirty",
as we are handling strings as short[].

 

-          Option 2: IDL string maps to java.lang.String in Java (which
uses UTF-16), CORBA::WChar * in C++ (which seems to be a wchar_t *), ...

o        Pros: No ambiguity. It is explicitly noted how an IDL data type
maps to any target programming language.

o        Cons: We shall have to map any IDL data type to any data type
of each target programming language. A default mapping might be set (if
we do not say anything, follow OMG IDL mappings, for example). We might
not follow the normative OMG IDL mappings. This makes me open a new
issue: what to do with programming languages commonly used and not
considered by the official OMG IDL mappings (PHP, .NET, Perl, ...).

 

I encourage, once again, working group members and general public to
read
http://www.w3.org/TR/2000/CR-DOM-Level-2-20000510/core.html#DOMString
[especially, the note at the end of the section] and also, for example,
http://lists.w3.org/Archives/Public/www-dom/1998JulSep/0415.html . As we
can see, the discussion is old and not yet finished.

 

Anyway, there are different options leading to a solution. We have to
choose one and be consistent to it. It is more important for me to
choose one and advance, and not spend more time on this subject as we
have a lot of work to do.

 

Best regards,

 

Nacho