chapters/3: Explicit external-reference ABNF #54
Conversation
chapters/3-package-information.md
Outdated
| `<type>` is an [idstring] that is defined in Appendix. | ||
| In Tag:value format, values must match the following [ABNF][rfc5234]. | ||
| `URI` is from pRFC 3986][rfc3986-s3]. | ||
| `space` is from [Appendi IV](appendix-IV-SPDX-license-expressions.md#overview). |
There was a problem hiding this comment.
space is getting added in #37, but if there is interest in getting this PR in first, I can reroll to require a single U+0020 space for the time being.
chapters/3-package-information.md
Outdated
|
|
||
| `<type>` is an [idstring] that is defined in Appendix. | ||
| In Tag:value format, values must match the following [ABNF][rfc5234]. | ||
| `URI` is from pRFC 3986][rfc3986-s3]. |
wking
force-pushed
the
external-references
branch
from
6eedc57
to
849b91a
Compare
wking
force-pushed
the
external-references
branch
from
849b91a
to
6e8b3bc
Compare
|
I've pushed 849b91a → 6e8b3bc, addressing Yev's concerns from #58 (except for |
wking
force-pushed
the
external-references
branch
2 times, most recently
from
1ef1616
to
9c2b5b7
Compare
wking
force-pushed
the
external-references
branch
from
9c2b5b7
to
5ecc05d
Compare
And renumber the old CC BY 3.0 from VII to VI.
This section has never been particularly tight. For example, the old: `<type>` is an [idstring] that is defined in Appendix. was probably intended to reference the old Appendix VII (removed by the previous commit). This commit ties them strictly to generic URIs (see discussion in [1]). That breaks compatibility with the old form, but since the old form was unclear, I think that's ok. The cpe entries are already URIs in their own right, although they aren't registered with IANA [2]. You can resolve them via [3] (e.g. [4]). There are also other currently-unregistered schemes for referencing packages, e.g. [5]. But managing all of that complexity isn't something that SPDX should handle. Instead, folks interested in providing stable packaging and security references should work on registering their URIs with IANA (or on establishing them in the SPDX ecosystem despite their not being registered). This commit also tightens the relationship between category values and their rdf:resource URIs. And it removes "OTHER" and instead encourages authors to define their own category name (and associated rdf:resource URI). [1]: spdx#53 [2]: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml [3]: https://nvd.nist.gov/products/cpe/search [4]: https://nvd.nist.gov/vuln/search/results?adv_search=true&cpe=cpe%3A2.3%3Aa%3Apivotal_software%3Aspring_framework%3A4.1.0%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A [5]: https://github.com/package-url/purl-spec
| @@ -946,56 +946,59 @@ Example: | |||
|
|
|||
| **3.21.3** Cardinality: Optional (one or many) | |||
|
|
|||
| **3.21.4** Data Format: `<category> <type> <locator>` | |||
| **3.21.4** Data Format: `<category> <URI>` <a name="3.21.4"></a> | |||
|
|
|||
There was a problem hiding this comment.
The term URI here can be confusing in an RDF/linked data context, because almost everything there is a URI.
| @@ -946,56 +946,59 @@ Example: | |||
|
|
|||
| **3.21.3** Cardinality: Optional (one or many) | |||
|
|
|||
| **3.21.4** Data Format: `<category> <type> <locator>` | |||
| **3.21.4** Data Format: `<category> <URI>` <a name="3.21.4"></a> | |||
|
|
|||
There was a problem hiding this comment.
Even if we had agreed on removing "type", it should first to remain as a deprecated field for one version of the spec. But I don't believed we had agreed on deprecating it. Have we?
There was a problem hiding this comment.
The term URI here can be confusing in an RDF/linked data context, because almost everything there is a URI.
How about <external-URI>? Or <reference-URI>? Or just <reference> and leave the URI-ness to the subsequent text?
Even if we had agreed on removing "type", it should first to remain as a deprecated field for one version of the spec.
That would be possible. The 2.1 wording was:
<type> is an [idstring] that is defined in Appendix.
The Appendix reference was fixed in 02aaac4, but that hasn't been released yet. So I don't think a breaking change with such an underspecified field is a big deal, but if we want to keep support through 3.0 (or even 4.0), I'd be ok with:
Data Format: `<category> [<type>] <URI-or-whatever>`But I don't believed we had agreed on deprecating it. Have we?
This PR is just my recommendations. Review and approval depends on whether we end up agreeing or not, but agreement doesn't have to be established before the PR is filed ;).
|
Closing this as stale. If disagree, please reopen. |
This section has never been particularly tight. For example, the old:
was probably intended to reference the old Appendix VII (removed by this pull request). This pull request ties external-references strictly to generic URIs (see discussion in #53). That breaks compatibility with the old form, but since the old form was unclear, I think that's ok.
The
cpeentries are already URIs in their own right, although they aren't registered with IANA. You can resolve them here (like this). There are also other currently-unregistered schemes for referencing packages, e.g. package URLs. But managing all of that complexity isn't something that SPDX should handle. Instead, folks interested in providing stable packaging and security references should work on registering their URIs with IANA (or on establishing them in the SPDX ecosystem despite their not being registered).Fixes #53.