"First, GraphML is an XML format and as such is post-processing friendly compared to proprietary (binary) formats. It is post-processing friendly in the sense that there a lots of standard technologies and tools to process XML."
In that perspective of "XML vs binary", I agree.
"Second (...) structure means the structure of the graph"
Agreed again, but from the mathematical point of view. From the point of view of the user using yEd :
- a label is some text that he/she associated to a node or edge,
- an icon is an image that he/she associated to a node.
Why does the user add labels and icons? Well, to add information. If the user sets a blue icon on some nodes, and a red icon on other nodes, then there's a chance that this means something to him, that this carries valuable information to him.
Now, looking at the current "GraphML+yWorks" file format, the same cannot be said for data that are only used by yEd to re-open and re-display the graph at a later stage, like the various coordinates.
"Third, your requirements are highly specific. Geometry data in a diagram is not clutter"
I realize I made a major mistake with this request : I have written "save" when I was thinking "export". The feature request is not about replacing the current in/out file format (GraphML+yWorks). The idea is to add another "export" format, which would export only the "structure + information introduced by the user" without the layout/coordinates elements. What you describe with the <data> tag being child of <edge> and <node> is precisely what I'm thinking of. Add texts and icons inside <data> and this is it.
Then yEd could be used as a general tool to "conceive" a graph. Once the graph is "perfect", then a programmer could export the structure (nodes, edges, groups) and "information" (labels, icons) in a clean XML structure.
I guess this won't make its way in yEd but anyway, thanks for your comments.