RE: Multiple fingerprints

["Larry Golding \(Comcast\)" <larrygolding@comcast.net>]

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?

 

Larry

 

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.

 

K

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.

 

Thanks,

Kar