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

OK, Rhys, thanks for you clarification. So the problem was with the name
of the data type itself.

 

The idea is then whether it is worth defining a new datatype to deal
properly with wide strings (UTF-16 encoded), although we might call it
in a different way (and not DOMstring) or use a different approach.

 

I agree with what Rhys says, about not using the name DomString and thus
better choose something like DDRString (if this approach is the one that
we resolve to follow).

 

Best regards,

 

Nacho

 

________________________________

De: Rhys Lewis [mailto:rhys@volantis.com] 
Enviado el: martes, 19 de junio de 2007 15:13
Para: Ignacio Marin; Rodrigo Garcia Acevedo; Mobile Web Initiative
Device Description Working Group WG
Asunto: 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