deletes externalId.md

[jeff-schutt]

The model currently contains both
model/Core/Properties/ExternalIdentifier.md and
model/Core/Properties/ExternalId.md.

The latter appears to be a duplicate with a very similar definition. This PR deletes the second file to ensure that there's only one such property for use in various types of SPDX 3.0 Elements.

[goneall]

Agree - we need to remove one of these - good catch

It looks like externalId is being used in the ExternalMap - so we should probably delete the externalIdentifier.

[jeff-schutt]

I suggest that we keepExternalIdentifier for multiple reasons:

• it's been better defined in the Summary and Description
• it is used directly in Element
• it is reused with specific meaning in the Security and Build profiles as well as for Agents, see examples

I saw in this example from @armintaenzertng where externalID is being used to reference another SPDX document as part of the ExternalMap.

My recent commit includes changes to support this, @goneall.

[goneall]

I have to admit, I'm now confused about the different types and definitions.

I think we want to have the ExternalMap have a property with an AnyURI range (which is what the old externalId was).

But I'm not sure what the ExternaIIdType would be used for.

[goneall]

OK - I think I figured it out - ExternalIdentifier is a property on Element where ExternalId is a property for the ExternalMap which has different semantics and property ranges.

So, we don't want to delete one of them.

This is, however, very confusing - even to those of us involved in creating this model.

I'm thinking we should rename ExternalId to ExternalElementUri to better distinguish between these 2 properties.

[jeff-schutt]

ExternalIdentifier is a property on Element where ExternalId is a property for the ExternalMap which has different semantics and property ranges.

IMO the semantics are so close and the property ranges overlap such that we should aim to consolidate the concepts.

On semantics:
It's worth noting that the ExternalMap is the value of the Imports property on ElementCollection. I suspect there's a path forward to expand the definition of ExternalIdentifier to convey the semantics of how it's used both on Element and on ElementCollection.

On property ranges:

I think we want to have the ExternalMap have a property with an AnyURI range (which is what the old externalId was).

model/Core/Classes/ExternalIdentifier.md has a property to specifically support this:

- identifierLocator
  - type: xsd:anyURI

[goneall]

IMO the semantics are so close and the property ranges overlap such that we should aim to consolidate the concepts.

@iamwillbar @sbarnum - what do you think? I recall William was a proponent of the externalId and Sean designed the ExternalMap with the externalId.

Since both Jeff and I got confused, I'm thinking we need to clarify the distinction somehow - but I don't feel strongly enough to delay 3.0 - although some of the proposed solutions would be breaking changes.

[zvr]

Discussed on 2023-10-23 tech call.

We probably want to rename the externalId property used in the ExternalMap class.

Consensus to use externalSpdxId -- and not rename the externalIdentifier property in the Element class.

[goneall]

I added a PR #519 to replace this PR based on the tech call.

@jeff-schutt - once you've reviewed the above PR, we should be able to close this one.

[jeff-schutt]

I don't believe #492 (comment) and #519 addresses the concerns I've raise above. The proposed solution (#519) to have separate external identifier properties in two places goes against the team's agreed-to principle to only have one way to represent a concept.

This PR includes a specific type of externalIdentifier used to indicate an spdx id outside of the current element or elementcollection. With this change, any external identifier can be represented the same way (spdx ids are a subset of all external identifiers) because they're all defined in the same vocabulary. This consolidates where external identifiers are described in the model to only one place.

The latest commit changes the ExternalIdentifierType to spdxId, consistent with what's proposed in #519: externalSpdxId, and adjusts the min and maxcount on ExternalMap to be aligned with the existing model.

Whenever constraints can be implemented, it would be worth a discussion on if the spec can constrain the externalIdentifier property when implemented in the ExternalMap such that it can only use 1 type: externalSpdxId. This would further ensure that the imports property is being used as intended.

In short, this PR consolidates how external identifiers are represented across the model, making identifiers less complicated for all. It doesn't treat SPDX identifiers differently than other external identifiers.

[jeff-schutt]

Suggested change

	- minCount: 0
	- minCount: 1
	- maxCount: 1

[jeff-schutt]

Suggested change

	- spdxdoc: An identifier for another SPDX Document, e.g. the other SPDX document's namespace appended by #SPDXRef-DOCUMENT as defined in the SPDX 2.3 specification: https://spdx.github.io/spdx-spec/v2.3/document-creation-information/#63-spdx-identifier-field
	- spdxId: An identifier for a SPDX 3 Element, SPDX 3 Collection, or SPDX 2 Document outside of this SPDX data, e.g. the other SPDX document's namespace appended by #SPDXRef-DOCUMENT as defined in the SPDX 2.3 specification: https://spdx.github.io/spdx-spec/v2.3/document-creation-information/#63-spdx-identifier-field

[goneall]

On the tech call on 5 December, we decided to go with the renaming of the field for 3.0 RC2 - closing this PR