/[gzz]/gzz/doc/pegboard/xu_link_space--benja/peg.rst
ViewVC logotype

Diff of /gzz/doc/pegboard/xu_link_space--benja/peg.rst

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.1 by benja, Thu Nov 14 16:35:36 2002 UTC revision 1.2 by benja, Thu Dec 5 00:13:22 2002 UTC
# Line 12  Line 12 
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
# Line 28  are not actually 'user contents' but are Line 24  are not actually 'user contents' but are
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
# Line 38  in the space etc. Line 45  in the space etc.
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

Legend:
Removed from v.1.1  
changed lines
  Added in v.1.2

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26