Visual Property Discussion

Existing System

UC1: CyNetworkViewReader constructs CyNetworkView with visual properties from a non-XGMML source.
UC2: CyNetworkViewWriter writes a non-XGMML CyNetworkView with visual properties to disk.
UC3: Plugin creates a visual style.
UC4: Plugin creates a discrete visual mapping.

[UC1,UC2] Very awkward to serialize visual properties for formats other than XGMML.
- Currently, we need to map between XGMML attribute strings and the target format's strings (e.g. GML).
[UC3] Visual properties of inaccessible types (e.g. org.cytoscape.ding.NodeShape) are awkward to set programmatically.
- Currently, you need to use a VisualProperty instance to construct a NodeShape instance by parsing the serialized form of the desired shape.
[UC4] Visual properties of inaccessible types (e.g. org.cytoscape.ding.NodeShape) are awkward to use with discrete mappers programmatically.

RenderingEngine implementations and I/O implementations cannot know about one another.

O1: No change. Let RenderingEngines handle visual property serialization.
- RenderingEngine implementation can only serialize to and from one format.
- Inhibited: UC1, UC2
- Awkward: UC3, UC4.

O2: Same as O1 but serialization format is not specific to any particular format.
- Converting between generic format and a particular file type's format is just a string mapping.
- Flexible, but potentially difficult to validate.
- List of allowable string values would need to be documented somewhere.
- Awkward: UC3, UC4.

O3: Let CyNetworkViewReader/WriterFactories handle visual property serialization.
- All visual property types would need to be exposed as API.
- RenderingEngines can still introduce arbitrary visual property types.
  - However, these would not be accessible programmatically unless the vendor also supplies an API bundle for the new types.