expand_less
After having already gotten some ways into this, I realize some of the initial premises were a bit off the mark. Some such are 1) cardspace logic doesn't actually depend on names, they are indepentent language grounded symbol spaces that are used to bind cardspace objects and structures, but are secondary to it. A separate (sub)system linked through type logic and methods. 2) Neither names, nor content are atomic. 3) Initial insights on combining namespaces being like mounting a filesystem in a filenamespace. Now we will consider that Namespace1+Namespace2 => Namespace3 such that it is defined how the bindings of 1 and 2 mix, particularly with collisions.
We must go through types, and more generally for card systems through set based subspaces, to be able to fully identify the type and specific methods bound within cardspaces. Thus our first definition:
CardIdentity is a typed token that relates two Cards in a equivalence relation.
These tokens may be scoped to a particular group of namespaces, therefore to join namespaces as above, we would translate Identity tokens as needed. It would be well defined, and in some scopes this can be integer tokens from lower layers of the representation (i.e. active record id fields in primary card db tables), but we can know these relative scopes with precision and hide in the implementations, expose for debugging.
SimpleCards are the only cards that can be bound in a namespace, thus implicitely naming any joined names and keys.
SimpleCards must be bound to a CardIdentity to be used, and conventionally it always has one or more names.
JointCard is Card joined SimpleCard
Card is JointCard or SimpleCard
Notably asymmetric. Maybe you want this branching on the right vs. the left as here. Both may be a semantics someone wants, but we do not consider it here.
Codenames are language independent names that are bound in codespaces.
Codenames are never translated and are not within any natural language. When codenamed cards are not given language specific names, any forms of translation may be invoked because these cards and their CardIdentities are permanently bound in and to the code.
Cardnames are the natural language bindings for a card.
These are the human presentable representations of cards. As described above, only SimpleCards can be bound to names and any JointCards.
SimpleCards don't have to actually exist to have names, and thus virtual JointCards can be constructed and we don't necessarily require that all the SimpleCard parts of a given JointCard actually exist. On the other hand, implementations may need to create some of these virtual parts in order to permanently bind to correct CardIdentity and CardKeys. Which reminds me we need:
Cardkey is an identity token that represents a unique name in all its variations.
E.g. for a Date, this might be and integer day number with a speced history bound DayZero. Or numerics might take on syntax from their NameSpace. This is speculative and we are exploring the future concept for Card Decks of Namespaces.
Current thinking is that Names bind within Namspaces and we need to define the semantics of namespace stacking to resolve:
FreeNames are symbolic atoms used in expressions, CardNames in all their complexities, CodeNames and CardIdentities for reference and storage/networked representation and reference.
We must go through types, and more generally for card systems through set based subspaces, to be able to fully identify the type and specific methods bound within cardspaces. Thus our first definition:
CardIdentity is a typed token that relates two Cards in a equivalence relation.
These tokens may be scoped to a particular group of namespaces, therefore to join namespaces as above, we would translate Identity tokens as needed. It would be well defined, and in some scopes this can be integer tokens from lower layers of the representation (i.e. active record id fields in primary card db tables), but we can know these relative scopes with precision and hide in the implementations, expose for debugging.
SimpleCards are the only cards that can be bound in a namespace, thus implicitely naming any joined names and keys.
SimpleCards must be bound to a CardIdentity to be used, and conventionally it always has one or more names.
JointCard is Card joined SimpleCard
Card is JointCard or SimpleCard
Notably asymmetric. Maybe you want this branching on the right vs. the left as here. Both may be a semantics someone wants, but we do not consider it here.
Codenames are language independent names that are bound in codespaces.
Codenames are never translated and are not within any natural language. When codenamed cards are not given language specific names, any forms of translation may be invoked because these cards and their CardIdentities are permanently bound in and to the code.
Cardnames are the natural language bindings for a card.
These are the human presentable representations of cards. As described above, only SimpleCards can be bound to names and any JointCards.
SimpleCards don't have to actually exist to have names, and thus virtual JointCards can be constructed and we don't necessarily require that all the SimpleCard parts of a given JointCard actually exist. On the other hand, implementations may need to create some of these virtual parts in order to permanently bind to correct CardIdentity and CardKeys. Which reminds me we need:
Cardkey is an identity token that represents a unique name in all its variations.
E.g. for a Date, this might be and integer day number with a speced history bound DayZero. Or numerics might take on syntax from their NameSpace. This is speculative and we are exploring the future concept for Card Decks of Namespaces.
Current thinking is that Names bind within Namspaces and we need to define the semantics of namespace stacking to resolve:
FreeNames are symbolic atoms used in expressions, CardNames in all their complexities, CodeNames and CardIdentities for reference and storage/networked representation and reference.