Re: [Gzz] New incomplete PEG-- please comment

[Tuomas Lukka]

On Thu, Oct 31, 2002 at 12:00:12AM +0100, Benja Fallenstein wrote:
> 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.

Applause. Excellent reasoning, and proposition.

But lots of problems: where do you *stop* the allowed formatting?
Should there be

        - bold
        - bold, underlined, 15pt
        - subscript/superscript (equations)
        - integral signs with bounds (a la TeX)
        - tables
        - images

Where is the line drawn?

This should probably be an issue.

> 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? 

Actually, this argument is a misunderstanding of the idea:
I first thought it would be like this and was against it because
of this. But: the idea was actually that the formatting links
would be a part of the *document*, and applied only to that
document.

> 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. 

But this is again true even in that model.

> 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, 

As I said above, this is not what would happen.

> 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.

But this is again correct.

> The second major problem is versioning. Formatting properties
> must be versioned; 

Same as above: this would work because the formatting would be
a part of the versioned unit.

> (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.)

Yes.

> 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. 

Good point.

> 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.)

Ah, so this *could* solve the cases I presented above... 

        Tuomas