From 8b78c0fe02715f1013ea858587822496fb5c937e Mon Sep 17 00:00:00 2001 From: Alexios Zavras Date: Sun, 11 Aug 2024 19:15:50 +0200 Subject: [PATCH 1/2] Fixes in Conformance chapter Signed-off-by: Alexios Zavras --- docs/conformance.md | 155 ++++++++++++-------------------------------- 1 file changed, 43 insertions(+), 112 deletions(-) diff --git a/docs/conformance.md b/docs/conformance.md index 76ac8e56e4..f51143ec90 100644 --- a/docs/conformance.md +++ b/docs/conformance.md @@ -3,13 +3,15 @@ ## 5.1 Alternate notation for some conformance requirements This standard contains more than a few cardinality assertions, each of which -indicates absolute, optional, or conditional requirements. +indicates the minimum and maximum number of times a property may appear. +These are represented by using "minCount" and "maxCount" respectively. +The absolute minimum number of occurrences is zero (0), +while for an unbounded maximum number of occurrences a star (\*) is being used. + Here are some examples: -- Cardinality: Mandatory, one. -- Cardinality: Optional, one or many. -- Cardinality: Mandatory, one if {condition} is true or {feature} omitted, zero - (shall be omitted) if {condition} is false. +- minCount: 1 +- maxCount: * - Cardinality: 0..1 - Cardinality: 0..* - Cardinality: 1..1 @@ -20,22 +22,22 @@ required, and if so, how many occurrences are required; also, whether a feature is permitted, and if so, in what number. As this is the format long familiar to the SPDX community, it has been preserved in this specification. -## 5.2 Introduction to Profiles +## 5.2 Profile compliance points Profile is the term for a compliance point within the SPDX community across The Linux Foundation and OMG. The System Package Data Exchange (SPDX) specification defines the following six compliance points, defined as “Profiles”: -- Core and Software Profiles (Clauses 6 & 7) -- Security Profile (Clause 8) -- Licencing Profile (Clause 9) -- Dataset Profile (Clause 10) -- AI Profile (Clause 11) -- Build Profile (Clause 12) -- Lite Profile (Clause 13) -- Extension Profile (Clause 14) +- Core and Software Profiles +- Security Profile +- Licencing Profile +- Dataset Profile +- AI Profile +- Build Profile +- Lite Profile +- Extension Profile -The Core and Software Profiles are mandatory. All others are optional. +The Core Profile is mandatory. All others are optional. ## 5.3 Core Profile compliance point @@ -106,6 +108,11 @@ serialization formats, including the classes and fields that comprise the SPDX License Expression syntax and that relate to the [SPDX License List](https://spdx.org/licenses/). +There are two associated profiles, the SimpleLicensing Profile +and the ExpandedLicensing profiles. +Both allow expression of the same information, +albeit in different ways. + Conformance to the Licencing Profile compliance point does not entail support for the Software, Security, Dataset, AI, Build, Lite, or Extension profiles of the SPDX. @@ -200,100 +207,24 @@ of the SPDX. This compliance point facilitates interchange of minimal licencing information when produced by tools supporting SPDX. -## 5.11 Extension Profile compliance point - -The Extension Profile captures extended tailored information when producing or -consuming non-standard SPDX content in three ways: - -- Support Profile-based extended characterization of Elements. Enables - specification and expression of Element characterization extensions within - any profile and namespace of SPDX without requiring changes to other profiles - or namespaces and without requiring local subclassing of remote classes - (which could inhibit ecosystem interoperability in some cases). - -- Support extension of SPDX by adopting individuals or communities with Element - characterization details uniquely specialized to their particular context. - Enables adopting individuals or communities to utilize SPDX expressive - capabilities along with expressing more arcane Element characterization - details specific to them and not appropriate for standardization across SPDX. - -- Support structured capture of expressive solutions for gaps in SPDX coverage - from real-world use. Enables adopting individuals or communities to express - Element characterization details they require that are not currently defined - in SPDX but likely should be. Enables a practical pipeline that identifies - gaps in SPDX that should be filled, expresses solutions to those gaps in a - way that allows the identifying adopters to use the extended solutions with - SPDX and does not conflict with current SPDX, can be clearly detected among - the SPDX content exchange ecosystem, provides a clear and structured - definition of gap solution that can be used as submission for revision to the - SPDX standard. - -Software that conforms to the SPDX specification at the Extension Profile -compliance point shall be able to import and export serialized documents that -conform with one of the SPDX serialization formats defined SPDX serialization -formats, including the abstract Extension class serving as the base for all -defined Extension subclasses. - -Conformance to the Extension Profile compliance point does not entail support -for the Licencing, Security, Dataset, AI, Build, or profiles of the SPDX but -is expected to be used in combination with the other profiles to extend them. - -This compliance point facilitates interchange of extended information that goes -beyond the standard SPDX produced by tools supporting SPDX and is used between -cooperating parties that understand the form of the extension and can produce -and consume its non-standard content. - -## 5.12 Standard data format requirements - -The data format specification and recommendations are subject to the -following constraints: - -- Shall be in a human readable form. -- Shall be in a syntax that a software tool can read and write. -- Shall be suitable to be checked for syntactic correctness automatically, - independent of how it was generated (human or tool). -- The SPDX document character set shall support UTF-8 encoding. -- Multiple serialization formats may be used to represent the information being - exchanged. Current supported formats include: - - - **YAML 1.2** - see: - [YAML Ain’t Markup Language (YAML™) version 1.2](https://yaml.org/spec/1.2/) - - **JavaScript Object Notation** (JSON) - see: - [ECMA-404](https://ecma-international.org/publications-and-standards/standards/ecma-404/) - - The JSON Schema for SPDX can be found in the - [SPDX specification Git repository schemas directory](https://github.com/spdx/spdx-spec/blob/master/schemas/spdx-schema.json) - - **Resource Description Framework** (RDF, also referred to as RDF/XML) - see: - [RDF 1.1 XML Syntax](https://www.w3.org/TR/rdf-syntax-grammar/) - - **tag:value** flat text file as described in this specification - - **.xls** spreadsheets - -- In addition to the supported formats, the following format is in development - with a plan to complete the specification in the next release: - - - **Extensible Markup Language** (XML) - see: - [Extensible Markup Language (XML) 1.0 (Fifth Edition)](https://www.w3.org/TR/2008/REC-xml-20081126/) - -- Interoperability between all the supported file formats shall be preserved. - SPDX defines how to validate a document in each supported format, and how to - translate a valid document without loss to each other supported format. - -- Tags and format properties are case sensitive. - -- Should be easy to recognize in a file system without opening the file. - A suggested naming convention is: - - | Format | Extension | - | ----------- | ------------ | - | tag:value | \*.spdx | - | RDF | \*.spdx.rdf | - | JSON | \*.spdx.json | - | XML | \*.spdx.xml | - | YAML | \*.spdx.yaml or \*.spdx.yml | - -- The convention in this specification is for the RDF examples to use - `rdf:about="..."` to represent that a proper Uniform Resource Indicator (URI) - should be present. +## Trademark Compliance + +To be designated an SPDX document, a file shall comply with the requirements of the SPDX Trademark +License, as stated in the [the SPDX Trademark Page](https://spdx.dev/trademark). + +The official copyright notice that shall be used with any verbatim reproduction and/or distribution of +this SPDX Specification 3.0.1 is: + +"Official SPDX® Specification 3.0.1 Copyright © 2010--2024 Linux Foundation and its Contributors. +Licensed under the Community Specification License 1.0. All other rights are expressly reserved." + +The official copyright notice that shall be used with any non-verbatim reproduction and/or distribution +of this SPDX Specification 3.0.1, including without limitation any partial use or combining this SPDX +Specification with another work, is: + +"This is not an official SPDX Specification. Portions herein have been reproduced from SPDX® +Specification 3.0.1 found at spdx.dev. These portions are Copyright © 2010--2024 Linux Foundation and +its Contributors, and are licensed under the Community Specification License 1.0 by the +Linux Foundation and its Contributors. All other rights are expressly reserved by Linux Foundation and +its Contributors." + From 192835d85da8ed73e8ae8cd17d47d57596dfd504 Mon Sep 17 00:00:00 2001 From: Alexios Zavras Date: Sun, 11 Aug 2024 21:47:34 +0200 Subject: [PATCH 2/2] Re-adds the mistakenly deleted conformance of Extension profile Signed-off-by: Alexios Zavras --- docs/conformance.md | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/docs/conformance.md b/docs/conformance.md index f51143ec90..3cb0c82dcc 100644 --- a/docs/conformance.md +++ b/docs/conformance.md @@ -207,6 +207,49 @@ of the SPDX. This compliance point facilitates interchange of minimal licencing information when produced by tools supporting SPDX. +## 5.11 Extension Profile compliance point + +The Extension Profile captures extended tailored information when producing or +consuming non-standard SPDX content in three ways: + +- Support Profile-based extended characterization of Elements. Enables + specification and expression of Element characterization extensions within + any profile and namespace of SPDX without requiring changes to other profiles + or namespaces and without requiring local subclassing of remote classes + (which could inhibit ecosystem interoperability in some cases). + +- Support extension of SPDX by adopting individuals or communities with Element + characterization details uniquely specialized to their particular context. + Enables adopting individuals or communities to utilize SPDX expressive + capabilities along with expressing more arcane Element characterization + details specific to them and not appropriate for standardization across SPDX. + +- Support structured capture of expressive solutions for gaps in SPDX coverage + from real-world use. Enables adopting individuals or communities to express + Element characterization details they require that are not currently defined + in SPDX but likely should be. Enables a practical pipeline that identifies + gaps in SPDX that should be filled, expresses solutions to those gaps in a + way that allows the identifying adopters to use the extended solutions with + SPDX and does not conflict with current SPDX, can be clearly detected among + the SPDX content exchange ecosystem, provides a clear and structured + definition of gap solution that can be used as submission for revision to the + SPDX standard. + +Software that conforms to the SPDX specification at the Extension Profile +compliance point shall be able to import and export serialized documents that +conform with one of the SPDX serialization formats defined SPDX serialization +formats, including the abstract Extension class serving as the base for all +defined Extension subclasses. + +Conformance to the Extension Profile compliance point does not entail support +for the Licencing, Security, Dataset, AI, Build, or profiles of the SPDX but +is expected to be used in combination with the other profiles to extend them. + +This compliance point facilitates interchange of extended information that goes +beyond the standard SPDX produced by tools supporting SPDX and is used between +cooperating parties that understand the form of the extension and can produce +and consume its non-standard content. + ## Trademark Compliance To be designated an SPDX document, a file shall comply with the requirements of the SPDX Trademark