Fixes in Conformance chapter

docs/conformance.md

@@ -3,13 +3,15 @@
 ## 5.1 Alternate notation for some conformance requirements <a name="5.1"></a>
 
 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 <a name="5.2"></a>
+## 5.2 Profile compliance points <a name="5.2"></a>
 
 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 <a name="5.3"></a>
 
@@ -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 <a name="5.11"></a>
-
-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 <a name="5.12"></a>
-
-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."
+