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. Whether that means every Element in a document with a namespaced ID MUST or MAY have an externalReference property is up for discussion - I think MAY is correct, documents shouldn't be forced to be resolvable resources.
I don't understand note On #3: - does "fragment-based ID" mean an ID where the namespace is not populated? For every Element serialized in a Document the default namespace is used if needed. If an Element is not associated with any Document then its ID MUST have a namespace. Is anything else required to make things tenable? For #4 I prefer an approach that allows hints to be ignored when testing for equality. When SBOMS get bigger than the software they describe, it is more scalable to divorce identification of elements from hinting, and ensure interoperability between hinted and non-hinted Documents. In practice Documents will be processed by tools, and every Element can have name, summary, description and comment properties to supply tools with plenty of hints, along with the Purpose properties we discussed today. Dave On Tue, Jul 27, 2021 at 11:57 AM Sean Barnum <[email protected]> wrote: > 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. > > > > 1. All Elements MUST have IDs that are globally unique and distinct > from each other > 2. Element IDs should be composed of a namespace controlled by the > producer of the Element and a non-namespaced-id portion that is unique > within the namespace > 3. Element IDs should be valid URIs/IRIs that support semantic > linked-data use cases > 4. Element IDs should provide some hint to element type/context to > improve human-readability > > > > > > While #1 is clearly the most fundamentally important requirement, I would > consider 2-4 to also be hard requirements from a practicality perspective. > > > > On #2, the namespace MAY be tied to a specific Document but is not > required to be. The namespace can be independent of any document. I would > assert the current model supports both cases appropriately. > > On #3, this means that fragment-based IDs are not allowed as fragments > within URIs are specifically limited to client-side processing and are NOT > handled at the server side including for http redirection. This makes them > untenable for linked data (and other http-based) use. > > On #4, there are a few different ways to handle this and we should discuss > options and tradeoffs to reach consensus on an approach as long as it does > not violate 1-3 > > > > > > Did I forget any key requirements above? I threw this list together > quickly based on issues I saw in the thread discussions and I may easily > have forgotten to include something. 😊 > > > > sean > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4128): https://lists.spdx.org/g/Spdx-tech/message/4128 Mute This Topic: https://lists.spdx.org/mt/84335757/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
