This breaks SDL semantics. The input parameters cannot be evaluated to discriminate the transition.

But the "present" operator is equally compact in terms of graphical representation. I do not think that a new syntax would improve readability

Look at the picture I attached for an example. There is just one call to "present" and as many branches as there are choices in the ASN.1 type.

(I think in your screenshot, you misuse the "present" operator. It does not return a boolean, it returns the actual choice item)

Many thanks for your quick reply and for the clarification of the "present" operator.

The problem remains, however, that I have to write mux/demux functions. This is because I am obliged to consume the signal at the input statement, when really I want the choices to be handled differently (or rejected) in the various states of my process. Mux/demux functions are ugly, as they they look like functionality when they are merely a modelling artefact.

How about a "split/join" symbol in the interface view instead?

I agree that you should not have to mux-demux message manually.

Why are you grouping your messages into a CHOICE in the first place instead of using multiple messages?

I'm modelling a transfer protocol on redundant serial buses. If I use multiple messages, then all those messages must be propagated over both arms of the bus, and to all its end points. The interface view gets pretty messy, and it's difficult to extend. Also it's harder to model the various layers of the protocol independently.

I can send you some stuff to show you what I mean, but I can't post it on a public forum.

Yes, please send me the models to maxime.perrotin@esa.int

I am working on getting this for you. It currently doesn't compile due to what I suspect is an OpenGEODE bug, so I have raised http://taste.tuxfamily.org/mantis/view.php?id=725 [^]

I think the problem is that not enough use is made of signal routes. In normal SDL, you can route sets of signals together and it appears as a single channel on the diagram. These can be split into individual signals inside lower level decompositions to connect to either blocks or processes (see routes1.png)

TASTE clearly has this concept (see sdl_block.png) but it is not possible to create hierarchies of blocks, so it is not useful. Allowing block hierarchy would solve the problem completely and would be a faithful implementation of SDL.

I moved the discussion here: https://gitrepos.estec.esa.int/taste/taste-setup/issues/3 [^]

Can you please comment there? (It's easier to include images in the text)