The characteristic that makes canonicalization interesting is that by
definition any canonical format can be converted to any other without
loss. If any of the alternatives in this issue or any other issue can't be
converted, then they aren't viable candidates. So picking among equivalent
alternatives will always be a matter of personal preference, not capability.
My personal preference is for 1) explicit structure and 2) compactness, so
I vote for the Array format. But I believe each of these alternatives is
equivalent to my favorite, so meh.
Note that the string format includes the type information "cpe:2.3". This
information must be known when using any of the alternatives, but is
normally communicated by the property name of the value, so the same
information in the string is redundant.
{"cpe-2.3": {,,,Object...}}
{"cpe-2.3": [,,,Array...]}
{"cpe-2.3": "cpe:2.3:...String..."}
Regards,
David
On Fri, Aug 5, 2022 at 7:21 PM Sebastian Crane <[email protected]>
wrote:
> Dear all,
>
> We had a very productive Canonicalisation Committee meeting today, in
> which we
> explored the many aspects of CPEs and discussed their representation in
> the SPDX
> Canonical Serialisation. There are two forms of CPE which we support as
> External
> Reference Types in SPDX: CPE version 2.2 from 2009, and CPE version 2.3
> from 2011. They differ a little from each other in terms of their usual
> string
> representation, but share the same basic constructs.
>
> During the meeting, we came up with three different JSON representations
> that
> would be suitable for encoding CPE information unambiguously. As all three
> could
> be used in the Canonical Serialisation, we decided to call a vote as to
> which
> was preferred by the SPDX community, including tooling developers
> intending to
> support the Canonical Serialisation for SPDX 3.0. Please feel free to
> vote, and
> make sure to cast it by means of a reply on this mailing list! :)
>
>
>
> --------------------------------------------------------------------------------
>
> 'Object' option:
>
> {"part":"a","product":"php5-common","vendor":"debian","version":"5.3.2-1"}
>
> 'Array' option:
>
> ["a","debian","php5-common","5.3.2-1"]
>
> 'String' option:
>
> "cpe:2.3:a:debian:php5-common:5.3.2-1:*:*:*:*:*:*:*"
>
>
>
> --------------------------------------------------------------------------------
>
> Please note that the Object option has key-value pairs sorted
> alphabetically by
> their key's name, as will be the case for all objects in the SPDX 3.0
> Canonical
> Serialisation.
>
> Versions 2.2 and 2.3 of the CPE specification are similar enough that
> we'll use
> the same format for both of them in the Canonical Serialisation.
>
> An important factor that we will discuss later (and which we're not voting
> on
> here) is how null (wildcard) attributes are represented. In these
> examples, I've
> omitted the null attributes for the Object and Array options, leaving out
> the
> entire key-value pair (for Object) and the null array elements (Array). We
> could
> just as easily define that the String option must also have trailing null
> attributes removed, and conversely we could specify that all attributes are
> present for the Object and Array options, requiring a special value (such
> as
> NULL or the empty string) as its value.
>
> I'll count the votes on Thursday the 11th of August. Feel free to discuss
> the
> relative merits of the options here on the mailing list, and I look
> forward to
> seeing which option wins! :)
>
> Best wishes,
>
> Sebastian
>
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4727): https://lists.spdx.org/g/Spdx-tech/message/4727
Mute This Topic: https://lists.spdx.org/mt/92846339/21656
Group Owner: [email protected]
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
