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