Arthit Suriyawongkul

Or we can have a "3.0.1-iso" milestone? "3.0.1-iso" name will indicate that this is a spec document that the textual content (for human consumption) is similar to the ISO publication...

Track changes since 3.0.1, see change log updates in #1001 (items with an asterisk * are changes that may go to `support/3.0` branch as well)

For v2.2.1, these are the tags we have - [v2.2.1](https://github.com/spdx/spdx-spec/releases/tag/v2.2.1) - [v2.2.1-ISO-submittal](https://github.com/spdx/spdx-spec/releases/tag/v2.2.1-ISO-submittal) - [v2.2.1-ISO-final](https://github.com/spdx/spdx-spec/releases/tag/v2.2.1-ISO-final)

Note: a "3.0.2" milestone has been created https://github.com/spdx/spdx-3-model/milestone/8

Also from the call, note that 1) regular expression character class is different from Unicode character class, so implementation in regex should notice the differences 2) each major JDK version...

Should we add this to the "Terms and definitions" chapter, in the spdx-spec repo? https://github.com/spdx/spdx-spec/blob/develop/docs/terms-and-definitions.md

Agree that we should have a set of "default imports" and pre-defined URI prefix/namespace. - See also https://github.com/spdx/spec-parser/issues/157

Related to this: https://github.com/spdx/LicenseListPublisher/issues/183 ?

Dataset Example 1 has a workaround by define the element itself, to pass the validation -- but this is of course should not be a preferred way. https://github.com/spdx/spdx-examples/blob/6a5d3a00fdc3d2bcdd9bb9959a0aa09c1f9dc801/dataset/example01/spdx3.0/example01.spdx3.json#L168-L175

Does there a way to tell `pyshacl` to skip a specific type error or errors from a specific type of element? If we can do that, we can still have...