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:
CardIcon is an alternative graphical icon bound to a card as an iconic variation.
This is speculative, and might give some additional power. Icons are potentially (if well designed) international signs with meanings translatable into languages. These probably should have codenames, and could have a special category of key that is related to the codename. Otherwise a textual name might need to be based on either an index within category (icons?) or a CardID token.
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.
Namespaces are maps of structured content
We are describing (mostly) a deck of Cards Type of Namespace with complete definitions and specifications of the Types above.
Namespace1 + Namespace2 => Namespace3
When the added namespaces are compatible and disjoint, addition is pretty simple and natural, just add as two sets of Name(or just ID)xTypedValue pairs. Name collisions are the complexity when not disjoint. When this occurs a semantics, a rule for choice can be used to resolve them.
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:
CardIcon is an alternative graphical icon bound to a card as an iconic variation.
This is speculative, and might give some additional power. Icons are potentially (if well designed) international signs with meanings translatable into languages. These probably should have codenames, and could have a special category of key that is related to the codename. Otherwise a textual name might need to be based on either an index within category (icons?) or a CardID token.
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.
Namespaces are maps of structured content
We are describing (mostly) a deck of Cards Type of Namespace with complete definitions and specifications of the Types above.
Namespace1 + Namespace2 => Namespace3
When the added namespaces are compatible and disjoint, addition is pretty simple and natural, just add as two sets of Name(or just ID)xTypedValue pairs. Name collisions are the complexity when not disjoint. When this occurs a semantics, a rule for choice can be used to resolve them.