Oooh! Let’s define "relevant" like we did for reportingDescriptorRelationship.kinds so that – again, like reportingDescriptorRelationship.kinds –the default for location.relationshipKinds is
[ "relevant" ] .
Having done that – and it hurts me to say this – I see that our location relationship design is inconsistent with our reporting descriptor relationship design. We should have done this for consistency:
Define an object locationRelationship with these properties:
target of type integer , required,
minValue : 0
kinds of type string[] , optional, default:
[ "relevant" ] .
In the location object:
Add a property id of type integer, optional,
minValue : -1, default: -1 ( no change from current design – relocated from
physicalLocation )
Add a property relationships of type
locationRelationship[] , optional, default:
[] .
In the physicalLocation object:
Remove the id property ( no change from current design – moved to
location )
Sorrier than I can say (and only partially facetious about that),
Larry
From: <> On Behalf Of Larry Golding (Myriad Consulting Inc)
Sent: Friday, April 19, 2019 5:49 PM
To: OASIS SARIF TC Discussion List <>
Cc: Harleen Kaur Kohli <>
Subject: [sarif] Relationship kinds
As part of our acceptance of #375 (location relationships), I took an action to drive a mailing list discussion about values for location.relationshipKinds , beyond the two values "includes" and
"isIncludedBy" that the issue defines.
So… any ideas? I will take 30 seconds now to ponder…
Some taint-related values? Like
"isSourceOfTaintedDataUsedBy" , "isSinkForTaintedDataUsedBy" , and "sanitizesTaintedDataUsedBy" . (pretty verbose, but I wanted to be clear about the relationships).
Thanks,
Larry
