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.

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.

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.

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.

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.

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 (#4143): https://lists.spdx.org/g/Spdx-tech/message/4143
Mute This Topic: https://lists.spdx.org/mt/84645574/21656
Group Owner: [email protected]
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-


Reply via email to