The SPDX project will be hosting an initial working "DocFest" to bring together the producers of SPDX documents and walk through the differences between tools for the same artifacts. Artifacts

I meant to send this to both the legal and tech lists, as I figured it might be of interest to both, but realized I forgot to add the tech list email, so forwarding now. - Jilayne Begin forwarded

Alexios, Jilayne: IMHO it would be a good time to revisit this. The case of license identifier does not and never did really matter otherwise. It does not matter to users. And most tools do not

Hi Jilayne, You can refresh your memory on the discussions (2015-2020) by readinghttps://github.com/spdx/spdx-spec/issues/63😉 I still like my example from that thread: Do we really want to

Hi Legal, Tech teams, I just want to clarify my understanding of capitalization sensitivity for SPDX license ids and license expression operators: Appendix IV states:

Looks great! Viele Grüße, Henk

If people haven’t seen it, our spec GitHub repo contains the diagrams produced by transforming the ontology to PlantUML: https://github.com/spdx/spdx-spec/tree/development/v2.2.1/ontology --

Hi Philippe, (I mistyped the spdx-tech address, fixed here) ~ Philippe Ombredanne [2021-07-28 12:04 +0200]: The ticket in the reuse-tool is public, the discussions with FSF were private with John

It does make sense. If SPDX accepts it as a valid design requirement, it also means that we MUST define a URI profile that uniquely identifies the boundary between namespace, document-supplied ID,

I agree that in 2.2 all Elements were tied to Documents. I believe the most fundamental change from 2.2 to 3.0 is that this is no longer true. This was a key principle for the 3T-SBOM collaboration

We discussed GraphViz and PlantUML today; here is the GraphViz version of the SPDX 2.2 information model (level of detail: conceptual). You can paste it into any number of tools, I like

Sorry for any confusion. By "fragment-based ID" I meant any ID containing “#” character which is interpreted as a resource fragment in the URI structure. In URI structure, any URI containing a

This would depend on the serialization format, for example, JSON-LD, XML-Schema have a native way of communicating an object’s type. For formats that don’t have that the type would need to be

My question was that in 2.2 every Element is known to be one of Document, Package, File, Snippet, OtherLicensingInfo, Relationship, or Annotation, because elements come only from Documents, and

I agree with key requirements 1-4. I agree with note On #2: A document provides a default namespace, and elements serialized within a document are allowed to have an id with an explicit namespace.

In the current model, Document has all properties of Element PLUS the “element” & “rootElement” properties PLUS the “externalMap” property PLUS the namespace property. The namespace

I believe there are a few key requirements we need to meet for our ID structure approach. These have been discussed before but I think they bear restating. All Elements MUST have IDs that are

In the current model under discussion, the only property of a Document is a namespace. So, your above assertions don't make sense to me. While I agree, you can refer to elements in other namespaces,

I would agree with 2, 3, 4 & 5 below but would take exception with 1. Based on my perspective of use cases and the extensive discussions we have had in the past I would disagree with two aspects

I am not sure if I am reading your comment correctly. If you are suggesting that ContextualCollection and BOM should be abstract then I would disagree as there are use cases for these independent of