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

Hello everyone, 
 
Just to try and clarify my position, I didn't have a problem with defining
'wide' strings. It was simply that the one that has been mentioned, namely
DOMString, is defined within DOM specifications which are client-side
APIs. It seemed a bit odd to use that particular data type within a
server-side API, such as the DDR.
 
I have no issue with using or defining datatypes for strings of wide
characters that are appropriate for server side use.
 
Best wishes
Rhys 

  _____  

From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On
Behalf Of Ignacio Marin
Sent: 18 June 2007 17:05
To: Rodrigo Garcia Acevedo; Mobile Web Initiative Device Description
Working Group WG
Subject: 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