-
Notifications
You must be signed in to change notification settings - Fork 24
Parser coalesces multiple edges between same nodes #3
Description
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(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?
