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 (#4101): https://lists.spdx.org/g/Spdx-tech/message/4101 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]] -=-=-=-=-=-=-=-=-=-=-=-
