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]> 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 > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4108): https://lists.spdx.org/g/Spdx-tech/message/4108 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]] -=-=-=-=-=-=-=-=-=-=-=-
