Ok, I'm reading, and I've got one question. It seems to me that without the prefixes, 3.0 becomes more extensible, for different items/identifiers/key-value pairs. Am I reading that correctly? (And if I'm totally backwards, I'm good with that. 🙂 )
________________________________ From: [email protected] <[email protected]> on behalf of Alexios Zavras via lists.spdx.org <[email protected]> Sent: Friday, July 23, 2021 5:11 AM To: Gary O'Neall <[email protected]>; [email protected] <[email protected]>; 'David Kemp' <[email protected]> Cc: 'Sean Barnum' <[email protected]>; 'SPDX-list' <[email protected]> Subject: Re: [EXT] Re: [spdx-tech] SPDX IDs - internal or meaningful? +1 for dropping the prefix requirement from the spec. In practice, many producers might use something to distinguish, e.g. license identifiers from annotation identifiers, but we can let each one come up with their own conventions. -- zvr From: [email protected] <[email protected]> On Behalf Of Gary O'Neall Sent: Friday, 23 July, 2021 04:39 To: [email protected]; 'David Kemp' <[email protected]> Cc: 'Sean Barnum' <[email protected]>; 'SPDX-list' <[email protected]> Subject: Re: [EXT] Re: [spdx-tech] SPDX IDs - internal or meaningful? The one advantage of having defined prefixes for the fragments is it helps to avoid collisions. That being said, I agree with William that we don’t need to retain these prefixes in SPDX 3.0. Dropping this constraint would still be compatible with 2.2 and would simplify the spec. Gary From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> On Behalf Of William Bartholomew via lists.spdx.org Sent: Thursday, July 22, 2021 6:06 PM To: David Kemp <[email protected]<mailto:[email protected]>> Cc: Gary O'Neall <[email protected]<mailto:[email protected]>>; Sean Barnum <[email protected]<mailto:[email protected]>>; SPDX-list <[email protected]<mailto:[email protected]>> Subject: Re: [EXT] Re: [spdx-tech] SPDX IDs - internal or meaningful? One thing I want to clarify is that in SPDX 2.2 the only constraints on the fragment (after #) are: * SPDXRef-DOCUMENT has special meaning and is used to refer to the document as a whole * License references start with LicenseRef- * External document references start with DocumentRef- * Other references start with SDPXRef- In SPDX 3.0 we have identifiers for more entities because we've made identities, relationships, etc. all "addressable", but the fragment is still opaque with no meaning inferred, I also don't think we need the restrictions of LicenseRef-, DocumentRef-, and SPDXRef- prefixes in SPDX 3.0. We may want to keep a special identifier for the document as a convention, but nothing technically requires that in the model today. William On Thu, Jul 22, 2021 at 8:52 AM David Kemp <[email protected]<mailto:[email protected]>> wrote: Gary, In v2.2 [idstring] is not a subcomponent of the fragment, it is the entire fragment portion of the fully-qualified identifier. There are ten SPDXID properties in your example file: <namespace>#SPDXRef-DOCUMENT <namespace>#SPDXRef-Package <namespace>#SPDXRef-fromDoap-1 <namespace>#SPDXRef-fromDoap-0 <namespace>#SPDXRef-Saxon <namespace>#SPDXRef-DoapSource <namespace>#SPDXRef-CommonsLangSrc <namespace>#SPDXRef-JenaLib <namespace>#SPDXRef-File <namespace>#SPDXRef-Snippet The part after the dash is a mixture of SPDX-defined types (DOCUMENT, Package, File, Snippet) and strings referring to source material (fromDoap-1, fromDoap-0, Saxon, DoapSource, CommonsLangSrc, JenaLib), which makes it hard for tools to extract meaning from those strings: "if it's the reserved name of one of the 7 sections then X, else Y". That's why I think your instinct to treat them as opaque, and derive meaning from other properties, was correct. If we use the three-part structure <namespace>#<uid>/<label>, then all SPDX 2.2 IDs could go verbatim into the label part, and the fully-qualified Element IDs would be: <namespace>#1/SPDXRef-DOCUMENT <namespace>#2/SPDXRef-Package <namespace>#3/SPDXRef-fromDoap-1 <namespace>#4/SPDXRef-fromDoap-0 ... <namespace>#20/LicenseRef-Beerware-4.2 <namespace>#21/LicenseRef-1 <namespace>#22/MPL-1.0 <namespace>#23/Apache-2.0 <namespace>#24/GPL-2.0-only <namespace>#25/LicenseRef-2 We don't have a 3.0 licensing "profile" or "extension" yet, so I'm guessing that license IDs and license Refs are both valid 3.0 idstrings as they are in 2.2. But if we define them to be opaque <label>s then anything is possible. Tooling uses the element <uid> to find the element and all of its properties, and <label> can be anything. The license list presumably wouldn't be a list of elements (god forbid), but it might have a namespace. Dave On Wed, Jul 21, 2021 at 10:59 AM Gary O'Neall <[email protected]<mailto:[email protected]>> wrote: I would suggest a starting point for the ID format to be the current SPDX 2.2 which uses the following: <namespace>#SPDXRef-[idstring] for elements, or <namespace>#LicenseRef-[idstring] for extractedLicenseInformation [idstring] is a unique (to the document) string containing letters, numbers, . and/or -. The only requirement for namespace is that it is unique and follows a URI format without “#”. Reasoning: * Compatible with previous versions of SPDX * Meets most of the criteria Sean mentioned below * Lossless mapping of URI based ID to short IDs for various non-URI based serialization formats (e.g. YAML, Tag/Value) * Prefixing with SPDXRef and LicenseRef makes it easy to create non-conflicting ID’s for objects outside the SPDX defined SBOM format (e.g., I would like to extend a document to include something not defined in SPDX but using the same document namespace) As I write this, I realize this violates the opaqueness principle which I agreed to previously. I would still keep the [idstring] opaque, but require the prefixes of SPDXRef- and LicenseRef- for the reasons listed above. I believe we can implement an SPDX 2.2 compatible ID naming convention and meet Sean’s points below. If this is not the case, we should discuss further to make sure we don’t create something which isn’t usable for all serialization formats. Gary Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de<http://www.intel.de> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4118): https://lists.spdx.org/g/Spdx-tech/message/4118 Mute This Topic: https://lists.spdx.org/mt/84335757/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
