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] Graphs design changes


Inline

 

I’ll make the changes.

 

From: Michael Fanning <Michael.Fanning@microsoft.com>
Sent: Friday, March 30, 2018 1:24 PM
To: Larry Golding (Comcast) <larrygolding@comcast.net>; sarif@lists.oasis-open.org
Subject: RE: [sarif] Graphs design changes

 

  • Not an open issue. The edge defines a source and target, so directionality is represented. For bidirectional links, you need to define two edges.
    [Larry]. Ah, right
  • Labels describe the elements of a fully formed graph, the nodes and its edges. In a graph traversal, we provider user-facing messages that, reviewed in sequence, take a user through a specific problem.
    [Larry] Sounds good.
  • Why have we named state ‘finalState’ in the traversal? Is that what we landed on for other constructs as well?
    [Larry] My thought was: When you enter the first node of a traversal, you start off in some state (graphTraversal.initialState) Then, as you traverse each edge, the state changes to edgeTraversal.finalState (although I supposed newState might be better). I’m open to better names, but I think the semantics I’m describing are good.

    AFAIK there isn’t another construct with similar semantics. In a
    threadFlow, there is no notion of nodes and edges. We associate a state with each location (codeFlowLocation.state). I have always assumed – although the spec is not explicit on this point – that the state reflects the program state before the line of code specified by that location is executed, which is the usual debugger experience.
  • A node should have a nestedGraphId or subGraphId. This points to another graph the collected nodes of which comprise the current node.
    [Larry] That’s better than what I currently have in graphs.txt, which is nestedGraph:graph.
  • We can’t currently allow a graphTraversal to step into a subgraph if it cares to, because we don’t provide a graphId on the edgeTraversal class. We could provide an optional subgraphId property on an edgeTraversal to support this case (if absent, the graph id would be assumed to be the one defined at the graphTraversal level.
    [Larry] Sounds good.

 

From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Comcast)
Sent: Friday, March 30, 2018 11:18 AM
To: sarif@lists.oasis-open.org
Subject: RE: [sarif] Graphs design changes

 

Another open issue is:

 

  • Do we represent the directionality of an edge?

 

From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Comcast)
Sent: Thursday, March 29, 2018 5:11 PM
To: sarif@lists.oasis-open.org
Subject: [sarif] Graphs design changes

 

I pushed a changed to Documents/ChangeDrafts/Active/graphs.txt that incorporates the changes we discussed at the TC meeting. I understand there’s still some discussion, for example:

 

  • Is there a distinction between a “label” and a “user facing message” on nodes and edges?
  • Exactly how do we incorporate sub-graphs?
  • Do we want to define additional properties on edgeTraversal?

 

But I’m going to start writing with what we have.

 

The easiest way to see the changes I just incorporated is to look at the commit.

 

Thanks,

Larry



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