DeckoSystems+archived names

New Take on Namespace Logic

Still a bit preliminary, needs a lot of summary and editing, top level doc is Card Continuum in my deck. I will add here and related cards here as I make clarify concepts.

I think this Card is more up to date and to the point. The other 'references out' from the first link are earlier starts at the framework for this Blueprint

I will attempt to summarize the motivation here. Most of the issues are addressed below, but I'm going to suggest some different basis for design going forward. I want to do away with any special syntax and be able to express everything in terms of joining of simple names, and binding content to names.

If we define virtual cards more generally, to say that for any card X, X+f represents a functional application of Card f (required to be a Simple Card). In this paradigm, no Simpler cards can be virtual. I propose that when you add two decks, or subsets of decks in this functional way. E.g.:

DeckA + subset(DeckB) => DeckA with the subset of B addef virtually.

Then we bind some constructed combination of a base deck (or decks) with virtually mounted subsets of other Decks. I won't treat all the cases here, but I suggest that this functional understanding of Decks as multiple namespaces that can be merged without additional syntax could be used to:

Disambiguate. Say DeckA and DeckB each have CardConflict use, so in the combined (+ operator for adding namespaces) Deck/Namespace gives DeckA:Cardconflict for CardConflict, but CardConflict+DeckB would get DeckB:CardConflict. CardConflict+DeckA would be interpreted as a name alias for CardConflict (when we have that).
Select specific langage for rendering/names. AnyCard+LanguageInstance would override context language selection. For example you could display the French translation in an English version of a card discussing correctness of translations.

Stacked Decks

Local decks are additional decks that are stored in the local database with a different deck_id. The deck_id is simply the card_id of a card representing the deck, whether it is local or remote. The deck_id for a Deck card will be for the deck it is stacked on (or null for the root deck), so a given card will be recursively stacked, eventually on the root deck.

For Decko Systems we want to configure Deck cards to refer to remote Decks (including the root deck -- a wagn instance is a Deck, even though there's no deck card).

The core principle here is that stacked and local decks should be virtually indistinguishable from a wagneer's standpoint. (obviously there will be laggards here, like WQL)

Each stacked deck will point to one and only one remote deck.

representation-wise, the stacking url cannot be represented under the deck (eg /deck1), because everything under the deck is stored remotely. so the rep might be something like

/Deck/deck1/stack_point

We should probably put this somewhere else. It is yet another topic about names, and deserves it's own cards if it is worth persuing.

Commutative Plusses

We know that /a/b and /b/a are different cards.

With the new meaning of "+", /a+b would be yet another card, but it would be the same card as /b+a.

Similarly, a+b+c would be the same card as: a+b+c, a+c+b, b+a+c, etc.

Questions:

What are some good sample use cases? (probably won't build until we have some good ones)
Could this be implemented as an option in SmartName?

representation:

card key takes some standard form (eg, alphabetical order)

card name free to take any form that can be reconciled to key (like all cards)

name references do not store seq

Inheritance

a deck can be explicitly configured to inherit from another deck, which would mean that the inherited card's context is interpreted in the context of the inheriting deck.

Eg, suppose there is a deck /D that is configured to inherit from /. And suppose there is no REAL card /D/*all.

In that case /D/*all would pull its context from /*all. But the search would be interpreted in the context of /D and would therefore include all the cards in /D/, not all the cards in /.

default behavior of new decks should probably be to inherit from closest parent namespace

sharks

monkeys

platypuses

everyone

DeckoSystems+archived names

New Take on Namespace Logic