RE: [sarif] Nested graphs: adopting Luke's proposal

["Larry Golding \(Comcast\)" <larrygolding@comcast.net>]

Luke,

 

Shouldn’t node.nestedGraphId:string be an array, node.nestedGraphIds:string[]? Can’t a node contain multiple child graphs?

 

That’s how I’ll write the change draft unless I hear otherwise.

 

Larry

 

From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Comcast)
Sent: Monday, May 7, 2018 9:06 AM
To: sarif@lists.oasis-open.org
Subject: [sarif] Nested graphs: adopting Luke's proposal
Importance: High

 

My sense of the TC’s discussion on nested graphs, combined with the attached thread, is that Luke’s “nested graphs” proposal has these advantages:

 

• It can only represent “valid” inter-graph traversals; that is, traversals where there is an explicit edge from the source graph to the target graph.
  My “nested traversals” proposal, OTOH, allows you to jump into any graph, even if the two graphs are unrelated. (That’s a bad thing.)
• It can represent a graph traversal that terminates within the nested graph (a common scenario).
  My “nested traversals” proposal, OTOH, only allows graph traversals which ultimately exits from the nested traversal.
• It can represent a logical hierarchy of graphs, allowing a viewer to visualize the hierarchy, and to collapse nested graphs.
  My “nested traversals” proposal, OTOH, does not represent this concept at all.

 

My “nested traversals” proposal has, AFAIK, only one advantage:

 

• It’s easier for a viewer to recognize a nested traversal, and to offer a debugger-like step into/step over experience. But in Luke’s proposal, a viewer can still do this; it just has to trace forward until it sees an exit from the nested graph before it can decide whether to allow a “step into”.

 

Based on this, I’m going to produce a change draft that removes nested traversals and implements Luke’s nested graphs proposal. Please speak up if you disagree.

 

Larry