12 |
|
|
13 |
Xanalogical links are currently stored in a different space, |
Xanalogical links are currently stored in a different space, |
14 |
because we do not want the cells that make up the link |
because we do not want the cells that make up the link |
15 |
to be shown as transclusions. However, this introduces |
to be shown as transclusions. |
|
additional complexity, such as the need to know about |
|
|
two different ``Space`` objects in many places, or |
|
|
to have a Storm pointer reference in the main space that allows |
|
|
loading the link space. |
|
16 |
|
|
17 |
Additionally, links are not the only place where we do not |
However, links are not the only place where we do not |
18 |
necessarily want transclusions to be shown. Other examples |
necessarily want transclusions to be shown. Other examples |
19 |
include marking spans to make links (we do not want |
include marking spans to make links (we do not want |
20 |
the mark cells to show), an applitude to render textured |
the mark cells to show), an applitude to render textured |
24 |
lower-level fabric of the system, we don't usually want |
lower-level fabric of the system, we don't usually want |
25 |
them to show up as transclusions. |
them to show up as transclusions. |
26 |
|
|
27 |
|
Additionally, this makes the concept of a space less pure: |
28 |
|
it introduces the need to know about |
29 |
|
two different ``Space`` objects in many places, or |
30 |
|
to have a Storm pointer reference in the main space that allows |
31 |
|
loading the link space. |
32 |
|
In reality, of course, the contents of the two spaces |
33 |
|
must be presented as a unit to the user (as Xanadu had |
34 |
|
documents with links in them as well as the document's main text, |
35 |
|
at least conceptually we have spaces with links in them |
36 |
|
as well as the cells & connections). |
37 |
|
|
38 |
Finally, links should be first-class members of a space, |
Finally, links should be first-class members of a space, |
39 |
available for connections. For example, it should be possible |
available for connections. For example, it should be possible |
40 |
to connect an explanation to a link (like 'this is related |
to connect an explanation to a link (like 'this is related |
45 |
|
|
46 |
Thus, I propose to put the links into the same space |
Thus, I propose to put the links into the same space |
47 |
and to have a more generally useful way for avoiding |
and to have a more generally useful way for avoiding |
48 |
to show them as transclusions. As for this way, for now I propose |
to show them as transclusions. Since whether a cell |
49 |
to have a dimension ``a.hidden-transclusion``; if |
is shown as a transclusion generally depends on the |
50 |
a cell has a posward connection on ``a.hidden-transclusion``, |
cell type, let's also introduce a structure |
51 |
it will not by default be shown in that kind of context. |
for cell types now: |
52 |
|
|
53 |
|
If a cell is not a headcell on d.cell-type, |
54 |
|
the headcell on that dimension is its type. |
55 |
|
(If a cell is a headcell on d.cell-type, it |
56 |
|
does not have a specific cell type assigned.) |
57 |
|
|
58 |
|
Now, for each cell type, we just need to decide whether |
59 |
|
it should be shown as a transclusion or not. |
60 |
|
There are various ways to do that; for example, we could |
61 |
|
specify that if ``type.s(d_no_transclusion, 1).equals("true")``, |
62 |
|
we do not show the transclusion, or some such. |
63 |
|
However, string matching seems like bad practice; |
64 |
|
we'd probably better have specific cells (URIs) denoting |
65 |
|
'true' and 'false' to connect to them. |
66 |
|
|
67 |
|
We should also probably not have an own dimension |
68 |
|
for specifying this attribute of a cell type, since |
69 |
|
we may want to introduce others and when there are ten |
70 |
|
or so this structure becomes really inconvenient to view. |
71 |
|
Therefore, let's have two general purpose dimensions here, |
72 |
|
``d.type-attribute`` and ``d..type-attibute-set``. |
73 |
|
Attributes will also be specific cells (URIs). |
74 |
|
For an attribute A and a cell type T, the value |
75 |
|
of the attribute will be the cell at the first |
76 |
|
intersection of the ``d..type-attribute-set`` |
77 |
|
rank starting at T with the ``d.type-attribute`` rank |
78 |
|
starting at A. For example:: |
79 |
|
|
80 |
|
__ |
81 |
|
A1 A2 / \ |
82 |
|
| | | | +---> d..type-attribute-set |
83 |
|
T1 --- true --- 103 --- 222 | |
84 |
|
| | | v |
85 |
|
T2 --- false --- 299 | d.type-attribute |
86 |
|
\___/ |
87 |
|
|
88 |
|
|
89 |
|
In this case, the value of A1 for T1 would be 'true'; |
90 |
|
the value of A1 for T2 would be 'false'; the value |
91 |
|
of A2 for T1 would be 103; and the value of A2 for T2 |
92 |
|
would be 299. (The intersection at '222' is ignored, |
93 |
|
because the '103' intersection comes earlier on the |
94 |
|
``d..type-attribute-set`` rank, which is what counts.) |
95 |
|
|
96 |
|
So, for the "don't show as transclusion" attribute, |
97 |
|
if there is an intersection between a cell's cell type |
98 |
|
and that attribute cell, and if that intersection |
99 |
|
is the 'true' cell or a clone of it, then the original |
100 |
|
cell will not usually be shown as a xu transclusion. |
101 |
(Of course, for diagnostic views, we may want to view |
(Of course, for diagnostic views, we may want to view |
102 |
such cells also.) |
such cells also.) |
103 |
|
|
104 |
Notes: |
Notes: |
105 |
|
|
106 |
- The respective applitudes creating the cells are responsible |
- The respective applitudes creating the cells are responsible |
107 |
for putting the additional connection in. |
for putting the cell type in. |
108 |
- Often, the connection on ``a.hidden-transclusion`` will |
- Ted has been suggesting that cells have cell types. |
109 |
simply be to the cell itself, thus forming a single-cell |
I don't know whether he intended to have cell types |
110 |
ringrank. Since it doesn't matter what the connection |
in the structure or externally, but since mapping them |
111 |
is to, this is convenient. |
into the structure is trivial, let's just do that. |
112 |
- The ``a.`` prefix is for 'attribute,' since this |
- Cell types will be well-known cells (i.e., the cells' URIs |
113 |
is an attribute of a cell. |
will be known, like a dimension's). |
114 |
|
|
115 |
\- Benja |
\- Benja |