I've used the profile. It makes sense if you want to define the IDL explicitly in your model but this would imply a PSM, platform specific model, as DDS is a platform implementation. The value of modelling at that level, i.e. at the implementation level, is what I question.
The purpose of DDS is to distribute data. Data is only part of a model. A model also has behaviours. A PIM, platform-independent-model, is defined with classes (or blocks in SysML). A model should appear the same at either end of the distribution. The provider and consumer should see exactly the same as they would see if talking directly.
In my view it is a waste to spend time modelling the corresponding structs needed to distribute the PIM. The distribution implementation should be generated directly from the classes and interfaces that define it depending on the environment setting, e.g. RTI_VC9. There would need to be rules for mapping the classes/interfaces to IDL but those are easily defined.
The sample I posted on dds-example-t694.html
aims to clarify this point. The stopwatch 'service' is modelled but then we have to go to the effort of generating the predictable DDS topic structs.
I'd like to see an SOA profile that allows us to stereotype distribution points. This would need to be coupled with environments that would autogenerate the corresponding carrier implementation. I want to be able to switch my carrier between DDS, MilCAN, CORBA, UDP etc... without having to redo my 'implementation model'. DDS refers to this as a data model but I am suggesting that to be a misleading term.