General considerations

GraphML itself only specifies how the basic structural elements (nodes, edges, and ports) should be represented in XML and provides a generic mechanism to bind arbitrary data to these elements. Graphical details, even just labels or basic coordinates, are not part of the core standard. Instead, information about how a graph could be rendered as a diagram and what information is attached to the graph elements is stored in these extra attributes for which there is no standard defined. While yFiles tries to use a consistent way on all different platforms for the _additional_ data, in order to maintain some degree of compatibility between different platforms, the formats used are currently tailored to make it possible to use the features of underlying platforms as much as possible. This results in structurally similar GraphML, and while all files implement the GraphML standard correctly, they are not fully compatible in the sense that not all additional data can be parsed out of the box without modifications in other platforms.

Compatibility between yFiles for Java 2.x and other yFiles platforms

GraphML files produced by yFiles for Java 2.x (e.g. the Desktop yEd graph editor application) use a very different GraphML dialect (a different set of data extensions) than files produced by other, more modern yFiles platforms.

The reason is that yFiles for Java 2.x uses a different way to serialize the layout and visual attributes of graph elements that is tightly bound to the underlying viewer implementation and cannot be easily adjusted to work with the newer viewer architectures such as in yFiles.NET/WPF, yFiles for Java 3.x or yFiles for HTML.

Unfortunately, there is no support for converting these formats out-of-the box. One problem is that some features from the Java side can not be faithfully represented on other platforms without custom code, e.g. GenericNode/EdgeRealizers, custom label modesl and graph item visualizations etc.). Nevertheless, since it is still GraphML, it is possible to use custom code to (partially) convert Java GraphML to other platforms.

When implementing such a solution, it is recommended to take the following aspects into consideration:

• Which features do you need to support, e.g. labels, custom label models, Java node ports, folding etc.? Often it is possible to reduce the complexity of the task by restricting yourself to a subset of the possible features (e.g. a limited set of realizers or label models)
• Do you want the imported items to behave the same as the original implementation, or do you only need a static import? Topics like label cropping, interactive label model behavior and the like will pose an additional difficulty.
• Is representing your visualization by using symbolic descriptions an option? I.e., provide additional attributes via the generic GraphML data binding mechanism that just describe the type of object and perform the actual styling in code that evaluates these attributes. A related topic is layout information: If you plan to run a layout algorithm after the import, anyway, it usually isn't necessary to parse geometry information.

A solution to parse a minimal set of attributes could look like in this sample: JavaConverter.cs

Converting other platform's files to yFiles for Java 2.x brings additional problems, since the GraphML implementation for yFiles for Java 2.x doesn't support many advanced features such as object sharing, custom type conversion etc. Writing the Java 2.x GraphML format at the source platform is often the easier solution.

Compatibility between other yFiles platforms (apart from yFiles for Java 2.x)

Other yFiles platforms produce GraphML files that use a variation of XAML to represent nearly all objects that are serialized. Therefore, it is often possible to read files from other platforms with the following approach:

• Replace platform specific namespaces by the ones needed for the target platform
• Provide markup extensions or custom deserialization handlers for features that are represented differently on both platforms. A typical problem is font/typeface information, which tends to be very different between different platforms.

Compatibility between yFiles for HTML 1.3 and yFiles for HTML 2.0

yFiles for HTML 2.0 introduced a new streamlined API with some incompatible changes compared to yFiles for HTML 1.3. Due to the incompatible API changes, GraphML files produced by version 1.3 cannot be deserialized by yFiles for HTML 2.0 out of the box.

To mitigate this incompatibility, a GraphML Compatibility Demo which can read GraphML files written in versions prior to 2.x. Subsequent serialization will result in a yFiles for HTML 2.x compatible GraphML file. Therefore, the conversion layer of the demo can be used to enable backwards compatiblity as well as converting existing GraphML files as part of the upgrade from yFiles for HTML 1.3 to 2.0 and newer.