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: Multiple fingerprints

Thanks Yekaterina. Yes, result.id (or, as we propose to rename it in Issue #159, result.instanceGuid) is optional (MAY be present).


Michael et. al., any thoughts on scenarios that would require result.fingerprints to be an object rather than an array?




From: O'Neil, Yekaterina Tsipenyuk <katrina@microfocus.com>
Sent: Saturday, May 12, 2018 9:52 PM
To: Larry Golding (Comcast) <larrygolding@comcast.net>
Cc: O'Neil, Yekaterina Tsipenyuk <katrina@microfocus.com>; Michael Fanning <Michael.Fanning@microsoft.com>; sarif@lists.oasis-open.org
Subject: Re: Multiple fingerprints


Hi there,


I think an array should be sufficient.

I also want to double check that result.id is optional because we don’t generate separate ids — the fingerprints are our ids.



On May 12, 2018, at 4:06 PM, Larry Golding (Comcast) <larrygolding@comcast.net> wrote:

As the spec stands, the result.fingerprints property is a JSON object, where the property values are computed fingerprints, and the property names are arbitrary values that identify the fingerprints.


Yekaterina, I understand that SCA needs multiple fingerprints so that it can recompute a fingerprint (perhaps if the algorithm changed?) and still keep the old value around. If that is your scenario, do you need each fingerprint to be associated with an identifier (the property name, in the current design), or would it be enough if result.fingerprints were an array?


Michael et al, is there any other scenario for multiple fingerprints than SCA’s? That is, is there any other reason to prefer an object over an array, or vice versa, for result.fingerprints? As the spec stands, it suggests that you could use the property names to identify different fingerprinting algorithms, and a result management system could choose among them to decide which sets of results were logically identical.






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