[Gzz-commits] gzz/doc/pegboard/xu_link_space--benja peg.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Benja Fallenstein <address@hidden>      02/12/04 19:13:22

Modified files:
        doc/pegboard/xu_link_space--benja: peg.rst 

Log message:
        Incorporate comments from previous discussion.
        Please comment; this PEG is ready for discussion again.

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/xu_link_space--benja/peg.rst.diff?tr1=1.1&tr2=1.2&r1=text&r2=text

Patches:
Index: gzz/doc/pegboard/xu_link_space--benja/peg.rst
diff -u gzz/doc/pegboard/xu_link_space--benja/peg.rst:1.1 
gzz/doc/pegboard/xu_link_space--benja/peg.rst:1.2
--- gzz/doc/pegboard/xu_link_space--benja/peg.rst:1.1   Thu Nov 14 11:35:36 2002
+++ gzz/doc/pegboard/xu_link_space--benja/peg.rst       Wed Dec  4 19:13:22 2002
@@ -4,21 +4,17 @@
 
 :Author:       Benja Fallenstein
 :Date:         2002-11-14
-:Revision:     $Revision: 1.1 $
-:Last-Modified: $Date: 2002/11/14 16:35:36 $
+:Revision:     $Revision: 1.2 $
+:Last-Modified: $Date: 2002/12/05 00:13:22 $
 :Type:         Architecture
 :Status:       Current
 
 
 Xanalogical links are currently stored in a different space,
 because we do not want the cells that make up the link
-to be shown as transclusions. However, this introduces
-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.
+to be shown as transclusions.
 
-Additionally, links are not the only place where we do not
+However, links are not the only place where we do not
 necessarily want transclusions to be shown. Other examples
 include marking spans to make links (we do not want
 the mark cells to show), an applitude to render textured
@@ -28,6 +24,17 @@
 lower-level fabric of the system, we don't usually want
 them to show up as transclusions.
 
+Additionally, this makes the concept of a space less pure:
+it introduces 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.
+In reality, of course, the contents of the two spaces
+must be presented as a unit to the user (as Xanadu had
+documents with links in them as well as the document's main text, 
+at least conceptually we have spaces with links in them
+as well as the cells & connections).
+
 Finally, links should be first-class members of a space,
 available for connections. For example, it should be possible
 to connect an explanation to a link (like 'this is related
@@ -38,22 +45,71 @@
 
 Thus, I propose to put the links into the same space
 and to have a more generally useful way for avoiding
-to show them as transclusions. As for this way, for now I propose
-to have a dimension ``a.hidden-transclusion``; if
-a cell has a posward connection on ``a.hidden-transclusion``,
-it will not by default be shown in that kind of context.
+to show them as transclusions. Since whether a cell
+is shown as a transclusion generally depends on the
+cell type, let's also introduce a structure
+for cell types now:
+
+    If a cell is not a headcell on d.cell-type,
+    the headcell on that dimension is its type.
+    (If a cell is a headcell on d.cell-type, it
+    does not have a specific cell type assigned.)
+
+Now, for each cell type, we just need to decide whether
+it should be shown as a transclusion or not.
+There are various ways to do that; for example, we could
+specify that if ``type.s(d_no_transclusion, 1).equals("true")``,
+we do not show the transclusion, or some such.
+However, string matching seems like bad practice;
+we'd probably better have specific cells (URIs) denoting
+'true' and 'false' to connect to them.
+
+We should also probably not have an own dimension
+for specifying this attribute of a cell type, since
+we may want to introduce others and when there are ten
+or so this structure becomes really inconvenient to view.
+Therefore, let's have two general purpose dimensions here,
+``d.type-attribute`` and ``d..type-attibute-set``.
+Attributes will also be specific cells (URIs).
+For an attribute A and a cell type T, the value
+of the attribute will be the cell at the first
+intersection of the ``d..type-attribute-set``
+rank starting at T with the ``d.type-attribute`` rank
+starting at A. For example::
+
+                           __
+            A1       A2   /  \         
+             |        |   |   |        +---> d..type-attribute-set
+   T1  --- true  --- 103 --- 222       |
+             |        |   |            v
+   T2  --- false --- 299  |     d.type-attribute
+                      \___/
+
+
+In this case, the value of A1 for T1 would be 'true';
+the value of A1 for T2 would be 'false'; the value
+of A2 for T1 would be 103; and the value of A2 for T2
+would be 299. (The intersection at '222' is ignored,
+because the '103' intersection comes earlier on the
+``d..type-attribute-set`` rank, which is what counts.)
+
+So, for the "don't show as transclusion" attribute,
+if there is an intersection between a cell's cell type
+and that attribute cell, and if that intersection
+is the 'true' cell or a clone of it, then the original
+cell will not usually be shown as a xu transclusion.
 (Of course, for diagnostic views, we may want to view
 such cells also.)
 
 Notes:
 
 - The respective applitudes creating the cells are responsible
-  for putting the additional connection in.
-- Often, the connection on ``a.hidden-transclusion`` will
-  simply be to the cell itself, thus forming a single-cell
-  ringrank. Since it doesn't matter what the connection
-  is to, this is convenient.
-- The ``a.`` prefix is for 'attribute,' since this
-  is an attribute of a cell.
+  for putting the cell type in.
+- Ted has been suggesting that cells have cell types.
+  I don't know whether he intended to have cell types
+  in the structure or externally, but since mapping them
+  into the structure is trivial, let's just do that.
+- Cell types will be well-known cells (i.e., the cells' URIs
+  will be known, like a dimension's).
 
 \- Benja