It would at least be good to publish examples showing unreadable
identifiers, since there are so many other places to put readable
information. Does it really harm comprehension to say:
{
"id": "a392e5",
"name": "/lib/arm-linux-gnueabihf/ld-2.19.so",
"description": "Library ld-2.19.so from libc6"
}
instead of
{
"id": "SPDXRef-Library-ld-2.19.so",
"name": "/lib/arm-linux-gnueabihf/ld-2.19.so",
"description": "Library ld-2.19.so from libc6"
}
And if a tool must put readable information in ids, can the spec define a
syntax for separating significant from insignificant parts, such as the
significant id ends at the first non-hex character. That would allow
"id": "a392e5"
"id": "a392e5-SPDXRef-Library-ld-2.19.so"
"id": "a392e5 Library ld-2.19.so from libc6"
to all refer to the same element?
Dave
On Tue, Jul 13, 2021 at 5:56 PM William Bartholomew <[email protected]>
wrote:
> I 100% agree with the opaqueness, I disagree with forcing "unreadable"
> identifiers. Having readable identifiers makes it easier for humans to
> create and read SPDX documents. In our spec where we share examples, having
> unreadable identifiers will harm comprehension. That being said, if a tool
> wants to generate unreadable identifiers that's entirely it's choice, but
> we shouldn't force that.
>
> On Tue, Jul 13, 2021 at 2:06 PM David Kemp <[email protected]> wrote:
>
>> We touched on a really important question today - should the Id string be
>> an opaque value whose sole purpose is to denote elements within a document,
>> or can/should it say something semantically recognizable to users of the
>> document?
>>
>> I'm strongly with Gary on this - the Id should be an internal value with
>> no meaning, and when qualified with another document's namespace it becomes
>> an external value with no meaning. When something meaningful like a PURL
>> is needed, it is supplied as a property rather than an Id.
>>
>> To make that obvious to readers of a document, I'd propose that the
>> syntax of the Id be limited to a few hex digits like a Git short commit id "
>> *dae86e*". This would allow both sequential numbers (0..n-1) and random
>> values unique within the document, and it would remove the temptation for
>> implementors to sneak anything else in. IMO, brevity and visually-obvious
>> meaninglessness are both virtues of this approach.
>>
>> How short? 6 hex digits (16 million elements in a single document) should
>> be sufficient, but if somebody thinks a document with 4 billion elements
>> might be useful, we could stretch it to 8 :-).
>>
>> Dave
>>
>>
>>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4102): https://lists.spdx.org/g/Spdx-tech/message/4102
Mute This Topic: https://lists.spdx.org/mt/84188539/21656
Group Owner: [email protected]
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
