You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 20, 2020. It is now read-only.
I understand the appeal of "squashing" edge definitions/attributes for parsing convenience (like it is show-cased in the README). However, I would argue this affects the semantics of the graph described in the dot file, since apparently dot interprets the two transitions as separate, whereas the dot-parser doesn't. This is also not limited to attributes. If you remove the label, the parser would only report a single transition n1->n2 {} whereas dot still renders two transitions.
I think the most compatible approach would be to drop the merging semantics and handle duplicate transition definitions (i.e. encountering multiple edges with identical source and target nodes) at client-level.
Do you agree with this proposition or would you rather want to stick with the existing merging approach?
The text was updated successfully, but these errors were encountered:
mtf90
added a commit
to LearnLib/automatalib
that referenced
this issue
Apr 4, 2020
Consider the following dot code:
which leads to the following image when rendered with
(Note that both transitions are interpreted as individual transitions).
When parsing the above dot file with the digraph-parser
the output is
whereas I would expect the output to be
I understand the appeal of "squashing" edge definitions/attributes for parsing convenience (like it is show-cased in the README). However, I would argue this affects the semantics of the graph described in the dot file, since apparently
dot
interprets the two transitions as separate, whereas the dot-parser doesn't. This is also not limited to attributes. If you remove the label, the parser would only report a single transitionn1->n2 {}
whereasdot
still renders two transitions.I think the most compatible approach would be to drop the merging semantics and handle duplicate transition definitions (i.e. encountering multiple edges with identical source and target nodes) at client-level.
Do you agree with this proposition or would you rather want to stick with the existing merging approach?
The text was updated successfully, but these errors were encountered: