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?
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
dotinterprets 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 {}whereasdotstill 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?