[Gzz] New incomplete PEG-- please comment

[Benja Fallenstein]

=====================================================
``styled_text--benja``: Formatted text as a primitive
=====================================================

:Author:       Benja Fallenstein
:Date:         $Date: 2002/10/30 22:59:12 $
:Revision:     $Revision: 1.1 $
:Status:       Incomplete
:Date-Created: 2002-10-30


In a modern computer system, *formatted* text should be
the primitive we normally deal with. Unfortunately,
all-to-often, users are only allowed to format *some*
text, not all (for example, text in a text document
may be formatted, but the title as entered in a dialog
box can't be). Many spreadsheet programs only seem to
allow formatting a whole cell, not individual characters
in it.

This is stupid: It should be possible to apply e.g.
emphasis in all text you enter.

This probably stems from the fact that the primitive in
the underlying programming language is the "string:"
a *non-formatted* list of characters. For the same reason,
xanalogical text is practically unthinkable.

In Gzz, let's make the primitive *formatted*, xanalogical
text. Like it should be possible to link to and transclude
all text, it should be possible to emphasize and color
all text, for example.



The main issue: Formatting links or not?
========================================

Tuomas has said he'd like to try out the way the Xanadu project
planned to do formatted text: through links. For example,
to emphasize some text, you'd make a link to it saying,
"Emphasize this!"

This is indeed an interesting idea (I suppose Tuomas has it
from Ted's Literary Machines book). The two main runners for
how to implement styled text seem to be:

- the Xu one: using external links;
- the boring one: storing the markup in the enfilade.

The Xu way of doing this would, for example, allow us to say
"This should be emphasized!" in one transclusion, and have
the emphasis appear in another transclusion as well.

However, there are two major problems with this exciting idea.
The first I discovered was: What if you have the same characters
in two different contexts? This can happen even in the same
document: the same text can appear in a header and somewhere
in the body, possibly in a reference to the header
or something. It would be impossible to decide whether the
characters should be linked as "header" or not. Also, if we
quote some text from another document, it is common practice
to add an own emphasis-- we wouldn't want our own emphasis
to appear in the original document, nor would we necessarily
want it to appear in *our* document when we give the original
quote a second time. We might want to give the quote first,
then analyze it, emphasizing different parts of it each time.

The second major problem is versioning. Formatting properties
must be versioned; it must be easy, for example, to emphasize
a piece of a document, then go back to the old, non-emphasized
version, then view the two side-by-side; it would be absolutely
unexpected to have the emphasis appear in the older version,
too. It is possible that we have different versions of the
same text (different in the formatting applied to them, too)
in two different cells on the screen, for example in Ted's
real cut-and-paste system.

If we store formatting properties as xu links, in order for
the formatting to work as expected in these cases, we'd need
to specify *which* format links should apply to each instance
of a piece of text. We'd have to list, "this link applies,
and this one, and this." That way, we could avoid that
applying a format to one version automatically re-formats
another version which was not intended to be re-formatted.

(I suppose the Xu project did this by simply only respecting
formatting links stored in the same document; this works
because in Xu, links are in a document context. Updated
versions of a document would have updated formatting links.
This, too, has the effects explained in the next paragraph.)

However, this means the whole concept loses the property
I really like about it: I can *not* apply emphasis in one copy
and automatically have it appear in another copy, where
I'd need it, too. It doesn't work because the computer cannot
decide which copies the format should be applied to,
and which not.

Now, this is a revealing similarity to the *order* of characters--
the vstream. In many cases, when I have two copies of the same
text, and I change something in one copy-- insert a character,
swap two words-- I would like this change to appear in the other
copy, too. However, in other cases-- especially when comparing
different versions/possibilities, I do *not* want the other
version to change. (In zzstructure, if I do want both versions
to change, I represent the transclusion using a clone, not the
xanalogical mechanism.) This is exactly the same as with the
formatting properties: the computer can't decide the problem,
so even though it might be convenient if it could do it right,
we don't make an attempt that could only do it wrongly.

I think this is a good argument for taking the "boring" way,
above: Implementing formatting in the enfilade. Conceptually,
an enfilade object is simply a list of spans (or, if you prefer,
characters); a "formatted enfilade object" will conceptually
be a list of spans each of which has zero or more "styles"
applied to it (or, if you prefer, a list of characters each
of which has zero or more "styles"). A style will simply be
defined by a URI (which means: a cell). It is up to outside
mechanisms to determine what the style means. (The point is
that styles should when possible be semantic, for example
"emphasis" or "author's address" etc., so that they can be
interpreted in different ways for presentation.)

In a true enfilade representation, this will be really efficient
to implement as a "DSPative property" in enfilade speak.
Basically this means that at the highest possible node
in the tree, you store the information, "All text inside this
node has style X applied to it." In this scheme, it is equally
cheap to apply a style to a single word, to a section or to
the whole document (for the same reason that both small- and
large-scale rearrangements are efficient; the order of spans
in the enfilade is also a "DSPative property;" in fact, it's the
name-giving "DSP" (disposition) property itself.)



Open Issues
===========

How to implement this...