Card sharks often find themselves wanting to integrate content across multiple decks. A few examples:
For these cases and others we need ways of linking, nesting, querying, and otherwise connecting cards across decks.
DeckoSystem integrations will share common patterns:
The simplest integration is a single card mapping. This could be implemented quickly; the content can dictate both the uri and the remote card identifier. The local name need not match the remote name. In fact, this functionality could be used for many kinds of non-Decko content.
More compelling still is the capacity to connect many cards at once. But doing so without namespace conflicts can be challenging, particularly since the remote deck will need to reserve the right to add cards without looking for conflicts in any and all decks that use its cards.
Therefore the primary conceptual need for deep DeckoSystem integration is namespace support. At present all Decko names are in a root namespace; there must be others. Here's one proposal for how that might work.
Proposals for improvements to card name handling.
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.
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).
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.