DDS15 — Order in which implied IDL and language mappings interact

There looks to be different interpretations between DDS vendors how implied IDL and language mappings interface. The specification lists in 2.3.3 the example of type Foo which results in the implied IDL DataWriter named FooDataWriter. On this implied IDL the concrete language mapping is applied, so with IDL to C++ we get FooDataWriter/FooDataWriter_ptr/FooDataWriter_var. But, what happens when the type is a IDL or C++ keyword, for example the type _public results in the implied IDL publicDataWriter, on which the IDL to C++ language mapping is implied, so to our idea you get _cxx_public/publicDataWriter/publicDataReader. The IDL to C++ language mapping only sees the identifiers as resulted by the implied IDL rules. Some vendors do generate _cxx_public/_cxx_publicDataWriter/_cxx_publicDataReader which means the implied IDL and IDL to C++ language mapping are strangely mixed. A generaic modeling tool for example only knows of implied IDL, a custom code generator generates the code for the specific language mapping.

The specification should give an example for _public, what does the programmer now get in a specific programming language, for example C++