In that example no, but if you have an example with multiple elements (packages, files, identities) and relationships between them it's quickly undecipherable. We want to do more examples that represent more complex scenarios to help people understand how to apply SPDX in those scenarios, and this would harm the comprehension of those examples.
I don't see the harm in allowing more readable identifiers even if they're opaque to the specification. For example, why should my "identity" element within a document have the identifier "a1b2c3" when it could just have the identifier "iamwillbar". It's still meaningless to the tools and the specification but it's much easier for a human to follow. On Tue, Jul 13, 2021 at 6:20 PM David Kemp <[email protected]> wrote: > 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 (#4103): https://lists.spdx.org/g/Spdx-tech/message/4103 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]] -=-=-=-=-=-=-=-=-=-=-=-
