Yes and no :-). With opaque fragments (no defined prefixes), producer tools are free to put whatever they want into the fragment. And consumer tools are prohibited from expecting anything in the fragment. Consumers that expect anything beyond uniqueness within the namespace will be non-interoperable with producers that don't meet their unstated expectations.
So if you want to call that producer freedom "extensible", fine, but it does not enable any new standard functionality. It could enable proprietary, non-standard functions within producer-consumer pairs, but that's difficult to prevent other than by a robust certification program. Dave On Sun, Jul 25, 2021 at 10:04 PM Joshua Marpet <[email protected]> wrote: > 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] <[email protected]> *On Behalf Of > *William Bartholomew via lists.spdx.org > *Sent:* Thursday, July 22, 2021 6:06 PM > *To:* David Kemp <[email protected]> > *Cc:* Gary O'Neall <[email protected]>; Sean Barnum < > [email protected]>; SPDX-list <[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 > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4119): https://lists.spdx.org/g/Spdx-tech/message/4119 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]] -=-=-=-=-=-=-=-=-=-=-=-
