OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sarif message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Hi Michael,


JSON itself doesn’t have the notion of “array length”, but you’re right that an API like Newtonsoft.Json would represent a JSON array as a .NET array, which has a Length property.


BUT! In Luke’s proposal, a graph traversal is a flat array of edge traversals, each of which refers to an edge, but some of the edges might point to another graph. There is no “nested array” whose length you can take. That was the one advantage of my proposal: you could identify a nested traversal in constant time.




From: Michael Fanning <Michael.Fanning@microsoft.com>
Sent: Monday, May 7, 2018 9:29 AM
To: Larry Golding (Comcast) <larrygolding@comcast.net>; sarif@lists.oasis-open.org
Subject: RE: [sarif] Nested graphs: adopting Luke's proposal


JSON arrays provide a length member, yes? So to efficiently determine whether the nested graph terminates internally or steps back into the current graph, the viewer only needs to consult the final edge in the nested graph edge array to see whether it returns to the current graph. i.e., a constant time look-up rather than by N of nested graph edges.


My browser test of a JSON snippet shows that length is a valid property of an array. Of course, someone needs to traverse the collection at least once to produce this value. But edge array consumers shouldn’t need to duplicate that work in order to provide step-over behavior, unless I’m missing something.



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.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]