Profiles, Namespaces, and deja-vu

[davaya]

We concluded that Profile has several different meanings:

• Profile Team - used as areas of interest, organizing into teams.
• Profile Namespace - grouping together "new" classes, properties & enumerations.
• Profile Conformance Point - Additional restrictions on the model that state if you claim to support the profile, then you must conform to these specifications. Fields may be in same namespace, or not in the same namespace.

The issue with NamespaceMap is similar, caused by conflating different reasons for using Namespaces:

• Namespace - an organization of artifact names by topic or area of responsibility, e.g., SPDX is responsible for managing the SPDX license list under the http://www.spdx.org/license namespace, and the SPDX v3 model under the http://rdf.spdx.org/v3 namespace.
• Namespace Prefix - a short string assigned to a Namespace for the purpose of making documents shorter and easier to read.
• Namespace Map - an assignment of a Namespace Prefix to a corresponding Namespace that is meaningful within a specific scope.

A v2.3 SBOM has names such as http://spdx.org/spdxdocs/spdx-example-444504E0-4F89-41D3-9A0C-0305E82C3301#SPDXRef-Package and http://spdx.org/spdxdocs/spdx-example-444504E0-4F89-41D3-9A0C-0305E82C3301#SPDXRef-DoapSource that identify items. Each name is composed of a namespace and a local-id, e.g.,

• http://spdx.org/spdxdocs/spdx-example-444504E0-4F89-41D3-9A0C-0305E82C3301# + SPDXRef-DoapSource
• http://spdx.org/spdxdocs/ + spdx-example-444504E0-4F89-41D3-9A0C-0305E82C3301#SPDXRef-DoapSource
• http://spdx.org/ + spdxdocs/spdx-example-444504E0-4F89-41D3-9A0C-0305E82C3301#SPDXRef-DoapSource

Namespace Map establishes the dividing line between namespace and local-id, and the line will be established differently for maps with different purposes:

• Global Namespace Map - common across multiple documents, defined in the model and persisted in the element store to enable re-use
• Document Namespace Map - used only within a single document/payload to shorten names within that document, not defined in the model, can be translated from document to document across all serialization formats that support it.

Because there will be billions of SPDX documents it is impossible to create a new global map entry each time a new document is minted. Using the 2.3 example, there cannot be a short prefix assigned to every GUID because the prefix would need to grow to as long as the GUID in order to remain unique as the number of documents increases. So only the second or third options are possible in a global namespace map.

But only a Document NamespaceMap is effective at shortening names within a document. A Document NamespaceMap can include both global entries (with long local-ids) and document entries (with short local-ids). Discussion of NamespaceMap use cases must include realistic SpdxIds and how a Global (defined in the model) NamespaceMap is used in serialized data.

Both XML (using xmlns) and JSON (using the native property:value object)

[goneall]

Maybe we should call the property in the "X" class a "prefixMap" to disambiguate the usage.

[davaya]

That name is fine:

• Global Namespace Map - common across multiple documents, defined in the model and persisted in the element store to enable re-use
• Prefix Namespace Map - used only within a single document/payload to shorten names within that document, not defined in the model, can be translated from document to document across all serialization formats that support it.

The as-yet-unnamed "X" class could mean:

• Physical X - a serialized payload in a specific data format with a hash/signature value that can be verified
• Logical X - a specific set of elements carried in a specific payload (with specific creation info), independent of serialization

A Prefix Namespace Map property could be defined in either Physical or Logical X elements. But that would be practically useless because it applies to only a single logical or physical document, and the same element E could appear in many physical or logical documents with different prefixes.

Only a Global Namespace Map would be useful in assigning reusable prefixes, and those aren't useful in shortening serialized data.

[goneall]

I'm going to move this to the 3.0 milestone to consider changing the name of the namespace map

[goneall]

From the tech call 2 April 2024: We agreed to leave this the same name for SPDX 3.0 - closing this issue. We can open separate issues for SPDX 3.1 if we have a non-breaking proposal.