Do you mean the use of "octet" within an IDL type or how that type gets mapped to a language type say in C++. For example DDS::Octet?

Regarding the first point you should be able to use "octet" anywhere in your IDL files, that is at the top level or within any modules...

The second point, how types are mapped to specific languages (C/C++/Java/C#) is defined in the IDL to language mappings (for example http://www.omg.org/technology/documents/idl2x_spec_catalog.htm#IDL2C++  in the case of C++).  There is no implied name space for any consructed type. The problem happens with primitive types such as the mapping for "octet", "float", "long" etc.

Traditionally when the IDL to C++ mapping was defined it was assumed that CORBA would be the only consumer. So they implication is that to avoid conflict with the native language types (e.g. long is a valid keyword in C++) those primitive types would map to something in the CORBA namespace (e.g. CORBA::Long). In hindsight this was limiting (if you mix types from two CORBA vendors in the same program, each defines the types its own way so you end up with multiple definitions). Also it unnecessarily ties IDL to CORBA. So now if you use another middleware (say DDS which uses IDL for type definition and also CORBA, then you want to make sure there is no conflict on the way the primitive types are mapped to the language).

To avoid these issues there are the vendors have two alternatives. Either use a different namespace in DDS. For example DDS::Octet, DDS::Long, etc. Or else map it to exactly the same CORBA:: types that the particular CORBA implementation you are mixing with will use.

Different DDS vendors use different approaches. If you are just using DDS then the DDS::Octet mapping is cleaner and avoids dependencies and potential conflicts when linking to other applications/libraries. If you are explicitly sharing the same IDL types with CORBA within a single application/process, then you need to map it to the same underlying type.

For example, in RTI's implementation we offer the choice. It is just a flag that you pass to the "rtiddsgen" compiler and we will map the primitive types to the "DDS::" or to the "CORBA::" name spaces. In the latter case we support specification of which CORBA vendor you want to use as there are some dependencies for his as well.

All this should have minimal or no impact on the application code which can use the "using" construct to avoid having dependencies, or else make a few typedef calls to map those types to something else.