Proposals for improvements to card name handling.
Joints
We should use "/" instead of "+" as the default joint for compound cards, because this follows common web patterns and suggests directionality. For example, many naturally assume that A+B = B+A, but cardnames do not follow this logic; those are two entirely different cards. There is no such confusion with A/B. Joints should be configurable. All the following examples will assume this change.
Joints in Context
Currently cardnames used in links, nests, and other references are interpreted in an absolute context. If card A links to [[B]], then B means B. We currently use +B in this context to mean A+B. In changing the joint to "/", that would mean /B means A/B, which is clearly confusing to anyone accustomed to the idea that paths beginning with "/" are absolute. It's also problematic for the namespace proposal below. Therefore we propose switching the meaning, so that from the context of A, B means A/B, and /B means B.
Decks (Namespaces)
The DeckoSystems proposal articulates one group of cases where namespaces are needed: integration of a remote dataset in which name collisions cannot easily be avoided. There are many other cases where someone might want to give a given name two different meanings. The proposed solution is a new "Deck" cardtype that would act as a namespace root whenever used in the first position of a new namespace.
The namespace would effectively reset the root of the cardname logic. Suppose A is a normal card and X is a Deck card. By cardname logic, the existence of /A/B/C implies the existence of /A, /B, /C, and /A/B, but not necessarily /B/C. (The left and right must exist, and the left is defined as everythign to the left of the rightmost name). By contrast, /X/B/C does not imply the existence of /B or /C. B and C are in the /X namespace but not necessarily in the root namespace. /X/B/C does, however, imply the existence of /X/B and /X/C, because B/C follows normal cardname logic within the /X namespace.
Decks can also be compound cards. Eg if /X/Y is a Deck, and there is /X/Y/B/C, then there must be an /X/Y/B and an /X/Y/C but not necessarily a /B or a /C.
Contexts within decks
Quick aside: there is admittedly some potential for confusion with the term deck, now commonly used to refer to decko sites, and the new namespace meaning, which would imply part of a decko site. On the other hand, the fractal pattern of decks within decks is very Decko. Within this document, when disambiguation is needed we will use "site decks" to refer to the umbrella deck and "deck cards" to mean the narrower namespaces.
Let's say you have a site deck running at mysite.com/mydecko, a deck card on that called "mydeck", and a card in that deck called "mycard". In the content of that card:
- Home would refer to mysite.com/mydecko/mydeck/mycard/Home (current card context)
- /Home would refer to mysite.com/mydecko/mydeck/Home (root of current namespace)
- //Home would refer to mysite.com/mydecko/Home (root of site deck)
- ///Home would refer to mysite.com/Home (root of host)
Mounting remote decks
At this point we can introduce a core DeckoSystems concept: mounting remote decks. The general idea is that there are special Deck Cards, which we will for the moment call MountDecks (FedDecks is probably too cute). MountDecks refer to local namespaces that incorporate cards from non-local decks.
A MountDeck card will need to specify the following:
- a URI for the source deck
- scoping information delineating the cards to be mounted
- authentication information in cases where the remote deck can be updated from the local deck
There will likely also need to be additional configuration, for example to specify policies regarding synchronization, local overrides, etc.
Given the framing above, it is quite conceivable that a MountDeck will refer to cards outside of the local context, either because the reference goes beyond the delineated scope or because the remote deck refers to something outside of its namespace as mentioned above. Such cards should be treated as a special category of "unknown" which may be given special views.
For example, imagine a local deck local that mounts a foreign deck remote/D at local/M. That would be, for example, that remote/D/A would be available at local/M/A. But suppose that remote/D/A card refers to something outside of its namespace, like remote/X; local/M/A doesn not have access to that card. (We're not specifying a solution here, only noting that the system needs to be robust in the face of such references).
Rules within decks
Arguably the most challenging component of namespaces involves the handling of rules, including both card rules and code rules. How are rules shared or not shared across namespaces? We do not have fully compelling answers for those questions yet, but some important questions are raised below.
For card rules, the short answer is that there will need to be an element of inheritance. For example, it may be desirable that a rule on /B+*right defined in the root namespace should by default also apply in the namespace X, for example to X/A/B. (But not on X/B, in which B is treated as a simple card in the X namespace). This immediately begs multiple questions. First, how do we even know if the B in /X/B is even the same name as /B? Part of what is desirable about namespaces is that the "same" name can used completely independently in different contexts. But surely there are cases where we want to bound such meanings across namespaces. For example, shared codenames will almost always imply that we are referring to the same card. Is that the only mechanism?
Furthermore, what if we wanted to override a given rule on /B+*right in /X. Could we do that at /X/B+*right? If so, we are potentially in some cases adding yet another dimension (namespace) to inheritance patterns that can get quite complex on Decko, where formats and sets and (in the case of preferences) users can intersect in complicated ways. The language proposal involves more inheritance still.
It is also worth noting that some but not all such rules will need to be shared when mounting remote decks. For example, without structure rules, mounting decks will not be able to render content correctly. But remote permission rules, by contrast, will typically not be shared, since local decks cannot authenticate remote users.
For code rules, the logic is simpler even if the implementation road is difficult. Simply put, local namespaces will often not be able to render remote cards correctly without the correct mods installed, so the mounted namespaces will need to publish their mod dependencies, and the mounting decks will need to install them.
Searches
It is clear that searches both within and across namespaces will be desirable. It is less clear what the default behavior should be, but it is probably most consistent with the rest of our context handling that the default context be limited to the current namespace and namespaces nested within it.
Implementation Notes
We have as yet few specs for namespaces, but it seems likely that all cards must have a deck_id, and deck_id + key must be unique.