SmartMDSD Toolchain CommObject DSL Syntax: using references


The documentation at shows the usage of ‘CommObjectRef’ or ‘EnumRef’ to refer another communication object definition.

However, in the latest “domain” repositories, I’ve found no usage of it.
Instead, references are implicitly resolved by identifiers.

Are CommObjectRef and EnumRef deprecated?
Can someone clarify this?



yes, they are deprecated. In the v2 Toolchain you needed an explicit
keyword (CommObjectRef and EnumRef) to use a communication object. In
the v3 generation, you can use it directly as you do with simple types:

CommObject CommComplexObj {
x: Double = 0.0

CommObject ComExample {
b : CommComplexObj



Thanks! Is there a revised version of the documentation already for v3, or a change log? from v2->v3?
Meanwhile, I’ll work upon latest examples of v3.6.


Unfortunately, there is no updated manual and migration guide yet. However, we are working on this. A bunch of tutorials will be available soon.


Quick question: which are the form of initialisation supported?

So far, I’ve found two types only:

  1. single-value initialization, example
CommObject CommDirection3d {
  azimuth: Double = 0.0
  elevation: Double = 0.0
  1. homogeneous init with single value, see covMatrix in the example below
CommObject CommBasePose {
	covInvalid: Boolean
	covMatrix: Double[9] = [0.0]
	updateCount: UInt32
	pose3D: CommPose3d
	timeStamp: CommTimeStamp

Are there other types?


@dstampfer, @ALotz, another question:
Each Communication Object DSL file (.types) is supposed to have one and only one repository description (CommObjectsRepository), or multiple repository definitions can be defined in the same sourcefile (.types)?

I don’t find this information in the documentation…


You can also use vect: Double[3] = [1 , 2, 3]

The intention is to have one CommObjectsRepository per project (thus only one per .types file – and even only one .types per project). This proved to be practical and is the way we use it.


In my opinion, this option and the syntactic sugar of initialising all the values from a single one is a confusing semantic choice. For example, how can you ensure that the following

vect : Double[2] = [1]

is correct, or one value is missing…?

That is what I’ve been assuming, but that is how the full SmartSoft toolchain uses the DSL (1 .types per project, 1 CommObjectsRepository per .types, ergo CommObjectsRepository per project). The fact that this is a practical choice only depends on the toolchain itself (for SmartSoft it is, but that may not be the case in general).

A different story is, if at the DSL design already, there is a constraint 1:1 mapping .types and CommObjectsRepository, or if multiple CommObjectsRepository are allowed within the same file .types.

So, the question is: should I assume this mapping constraint being a DSL design choice, or I am free to use it as I like?


I have a question related to this.
I know I can add a references when I create the CommObject, but how do I modify (add/remove) existing references after creation?

For example if I need to refactor my existing CommObjects


Technically you can define multiple .types files per project, however, this is discouraged (and the project wizard only creates one file per project on purpose to reflect this best practice). As Dennis said, we have made a positive experience with bigger domain model repositories where it paid off to be consistent and to use one types file and one CommObjectsRepository per project. Yet, this is more of a best practice, rather than a hard DSL design choice.


I am not entirely sure what you mean. Do you probably mean, how to remove dependencies from one CommObjectsRepository to others? For example, some CommObjects in the CommNavigationObjects Repository use (i.e. reference) external CommObjects from the CommBasicObjects Repository. Now, as an example you would like to remove this dependency (hypothetically)? If this is you questions, then the answer is as follows. We are using here a standard feature of all Xtext based DSLs. By default, all Xtext DSLs find external dependencies over the Java Classpath. Therefore, if you need to use CommBasicObjects within the CommNavigationObjects repository, then you need to add a Project reference into the Java Classpath of the CommNavigationObject project settings. And if you want to delete this reference, then again, just modify the project’s Java Classpath accordingly. Just right click on the project within the Project Explorer window in Eclipse, go to “Properties”, then to “Java Build Path” and finally open the “Projects” tab. Here you can manage all the Project dependencies as you need.