Skip to content
This repository has been archived by the owner on Jul 20, 2020. It is now read-only.

Parser coalesces multiple edges between same nodes #3

Open
mtf90 opened this issue Mar 12, 2020 · 0 comments
Open

Parser coalesces multiple edges between same nodes #3

mtf90 opened this issue Mar 12, 2020 · 0 comments

Comments

@mtf90
Copy link

mtf90 commented Mar 12, 2020

Consider the following dot code:

digraph test {
    n1 [label = "Node 1"]
    n2 [label = "Node 2"]

    n1 -> n2 [label = "Input 1"]
    n1 -> n2 [label = "Input 2"]
}

which leads to the following image when rendered with

dot test.dot -Tpng -o test.png

test

(Note that both transitions are interpreted as individual transitions).

When parsing the above dot file with the digraph-parser

public static void main(String[] args) {
    GraphParser parser = new GraphParser(Test.class.getResourceAsStream("/test.dot"));
    Map<String, GraphNode> nodes = parser.getNodes();
    Map<String, GraphEdge> edges = parser.getEdges();

    System.out.println("--- nodes:");
    for (GraphNode node : nodes.values()) {
        System.out.println(node.getId() + " " + node.getAttributes());
    }

    System.out.println("--- edges:");
    for (GraphEdge edge : edges.values()) {
        System.out.println(edge.getNode1().getId() + "->" + edge.getNode2().getId() + " " + edge.getAttributes());
    }
}

the output is

--- nodes:
n1 {label=Node 1}
n2 {label=Node 2}
--- edges:
n1->n2 {label=Input 2}

whereas I would expect the output to be

--- nodes:
n1 {label=Node 1}
n2 {label=Node 2}
--- edges:
n1->n2 {label=Input 1}
n1->n2 {label=Input 2}

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?

mtf90 added a commit to LearnLib/automatalib that referenced this issue Apr 4, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant