[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Relationship kinds
|
Yekaterina, I took the directionality of the relationships from the definitions used by CodeSonar, as pasted by Paul into this
issue comment. I agree that it is confusing, but (aside from the lateness of the hour), I don’t want the spec to have definitions that are the exact opposite of what CodeSonar uses. Sorry for this, Larry From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org>
On Behalf Of Yekaterina O'Neil
While in locationRelationship.kinds, the values identify relationship from theSource to theTarget (e.g. “includes” and “isIncludedBy”), it seems like in reportingDescriptorRelationship.kinds, the values don’t
always identify relationship from theSource to theTarget, but raher from theTarget to theSource, and I find it confusing. For example, “superset” is defined to mean that theTraget is a superset of theSource, while to me it makes more sense to say that it means
that “superset” = theSource is a superset of theTarget. Same goes for “subset”, “canFollow”, “canPrecede”, “willFollow”, and “willPrecede”. Perhaps, I am the only one who feels these are defined backwards? k From: sarif@lists.oasis-open.org [mailto:sarif@lists.oasis-open.org]
On Behalf Of Larry Golding (Myriad Consulting Inc) The change draft is available: … and I merged the changes into the always-up-to-date provisional draft: Thanks, Larry From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org>
On Behalf Of Larry Golding (Myriad Consulting Inc) I placed the revised proposal in an
issue comment, including a revised sample, which I include here because I like it so much: "results": [ { "locations": [ { "id": 0, "physicalLocation": { "artifactLocation": { "uri": "f.h" } }, "relationships": [ { "target": 1, "kinds": [ "isIncludedBy" ] } ] } ], "relatedLocations": [ { "id": 1, "physicalLocation": { "artifactLocation": { "uri": "g.h" }, }, "relationships": [ { "target": 0, "kinds": [ "includes" ] }, { "target": 2, "kinds": [ "isIncludedBy" ] } ] }, { "id": 2 "physicalLocation": { "artifactLocation": { "uri": "g.c" }, }, "relationships": [ { "target": 1, "kinds": [ "includes" ] } ] } ] } ] Larry From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org>
On Behalf Of Larry Golding (Myriad Consulting Inc) After discussion with Michael: we believe that this change is both desirable from a design consistency standpoint, and in keeping with the spirit of what the TC approved. It does not add, delete, or change the semantics of any properties,
it simply packages two of the properties into an object for consistency with what we did for reporting descriptor relationships. So I will write the spec this way unless somebody objects (in which case, of course, we’ll discuss it). Larry From: Larry Golding (Myriad Consulting Inc) <v-lgold@microsoft.com>
Let me modulate my message there. The two designs are indeed not consistent, and one way to make them consistent – if we think that’s desirable – is what I described. But I make no proposal about what, if anything, we should do about it. Larry From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org>
On Behalf Of Larry Golding (Myriad Consulting Inc) 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:
Sorrier than I can say (and only partially facetious about that), Larry From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org>
On Behalf Of Larry Golding (Myriad Consulting Inc) 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]