To me, it’s always been strange that we speak of “node editors” as the concept here, when the defining abstraction is the data structure of a node graph represe

To me, it’s always been strange that we speak of “node editors” as the concept here, when the defining abstraction is the data structure of a node graph representing a dataflow. Specifically: • with the graph having an associated schema that defines node types; • where each node type has fields, properties, and connectors; • where fields are (potentially runtime data-bound) inputs, with types that define their data type, bounds, quantization, etc. and thus equate to a single optimal choice of input control; • where properties are like fields, but always runtime data-bound, and read-only; • where connectors are the actual graph vertices; are owned by specific nodes; are directional (in/out/inout); pair with other connectors on other node types, with connections permitted through each connector specifying an interface type that matching connectors must implement; • where node-level connectors have a “purpose” (registered UUID) that may define how they are rendered at the UX level (e.g. “input” purpose = top or left sticky-outy knob; “plugin inout” = black internal rectangle; etc) • where all fields have implicit inout connectors to control and/or sample their value; and where all properties have implicit out connectors to sample their value. (Also, optionally: with sets of nodes able to be encapsulated into groups, with connectors of nodes exposed as connectors of the group, and connectors outside the group able to connect only to the group’s exposed connectors.) A nodal dataflow graph document, then, would consist of 1. a schema (embedded or referenced); 2. a set of nodes, with groups; 3. the initial values for all fields without schema-specified default values; and 4. the connection edges between connectors. Note how none of that defines what a program should actually do with a given nodal dataflow graph document, even when it has a well-defined schema. This is on purpose; to me, a “nodal dataflow graph document” should be a thing like an XML document — able to be processed by domain-specific tools, but also by general-purpose tools. A nodal-dataflow-graph editor, could potentially be such a general-purpose tool. (When using general-purpose tooling, you’d lose any rendering for domain-specific types in fields/properties, and you wouldn’t be able to “run” the graph… unless these documents could point to logic allowing a generic editor to understand domain types — like HTML5 does with JavaScript-based Custom Element definitions.)