On Tue, Aug 3, 2021 at 11:34 AM David Kemp <dk1...@gmail.com> wrote: > Kate may be right that we'll need a whitepaper. But not just yet. Here > is what I heard today: > > 1) namespaces must be globally unique, and UUIDs in practice collide, in > part because they don't have a full 128 bits of uniqueness because they > contain built-in structure, and in part because even 128 bits isn't > enough. So just for discussion/whitepaper purposes, assume that namespaces > are 256 bit cryptographically-random values. >
I didn't hear that suggestion, any valid URI can be a namespace (possibly with some restrictions depending on the namespace + local id separator). This creates a space where clashes are unlikely, especially if namespaces are chosen based on something already controlled by the creator of the element. 2) elements are always identified by namespace and local ID, where local > means under the control of the namespace owner. Don't get hung up on what > owner means - anybody can become an owner by generating a 256 bit > random number for their namespace. > We're not proposing a model where namespaces are "controlled", which would require either a central authority or some form of challenge-response process for verifying control. Nothing would stop me declaring elements in your namespace, what I can't do is sign an SBOM as you. > 3) Element identifiers are built into the model. The diagram shows > Element having an "idString" property, but what it should have is namespace > and local_id properties that together form the primary key for the > element. Sebastian is correct, a separator isn't needed in the model > because that only comes into play when serializing Element identifiers. > I'll defer to Gary and Sean on the practicality of separating these. In general, having single properties for identifiers is easier, especially when they're referred to frequently (such as in relationships), so I'm dubious of the value of separating over having a composite identifier. > 4) Each serialization of Element identifiers MUST allow them to be > unambiguously deserialized back to namespace and local_id properties, which > is where the separator comes in. If the deserialized value doesn't have a > namespace then the Element inherits it from its containing document, or if > the element doesn't have a document or other source for namespace, the > local_id by itself is invalid. > Agreed. > 5) (My pet issue) although a namespace owner can choose anything as > local_ids, Element also has information such as Class, name, and comment > that can be used as a hint/label when serializing Element IDs. > Agreed. Building namespace and local_id into the model explicitly provides a > foundation for discussing and accommodating all use cases. IdString is an > obstacle to that discussion. > > Dave > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4144): https://lists.spdx.org/g/Spdx-tech/message/4144 Mute This Topic: https://lists.spdx.org/mt/84645574/21656 Group Owner: spdx-tech+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
