Re: [Gzz] Linked or associated nodes vs. xuLinked enfilades

[Tuomas Lukka]

On Sat, May 10, 2003 at 12:50:06AM +0300, Matti Katila wrote:
> 
> Well, this issue drives me crazy. Too much thinking. There are too many
> variables, too many pros and cons.

Welcome to the world of software design and engineering ;)
This is I believe all have 

> Some history:
> 
> In ancient times there used to be one node and some text in content of 
> the node. It was quite nice to be able to link in structure a node to 
> other one. Not a link like xuLink but content could be changed and the 
> link would stay as it is. 

I.e. a *structural* link. A connection in the RDF structure.

> This would be enough for ancient times and for ancient people but today 
> more and more of users want to be able to edit the text without worrying 
> where the node ends and next begins, 

How exactly must the user be aware where a node ends and another one begins?
An alternative structure: all text of a single "stream" in one node.

> i.e. it was not doable to link two 
> nodes one after other and then edit the content

Why? How?

> (some thanks to 
> linebroken too (linebroken was designed to simple paragraphs so it is 
> justified for it to not be good for canvas use)).

What? Now you've lost me. What does "linebroken" refer to, exactly,
and what exactly does it have to do with this?

> 
>    {Marry has a lamb.} {Marry is a girl.}
> 
> There's no structure to keep these two nodes separately but linked because 
> of context(same paper and next of other). 

You mean *spatial* structure. That *is* also structure.

(BTW: it's "Mary", not "Marry" - to marry is a verb.)

> There's no structure to say at 
> least {Marry has a lamb.} next sentence is {Marry is a girl.}.

Spatial structure.

Another way: put both texts in same node.

Third way: new RDF structure.

> This implicates that having no structure for nodes one after other makes 
> none of text editability.

implicate = To bring into connection with; to involve; to connect; --
                applied to persons, in an unfavorable sense; as, the
                evidence implicates many in this conspiracy; to be
                implicated in a crime, a discreditable transaction, a
                fault, etc.
                [1913 Webster]

imply = logical consequence

I don't understand the fragment "makes none of text editability" at all.

do you mean "Implies that text editability is impossible"? How?


> Different approach:
> 
> Just put things as always, one node and text into content, and use 
> xuLinks. 

xuLinks for what? For "next sentence"?

> Pros naturally is that linebroken can be used, or can we?

Why? How? What? (again, what *exactly* does "linebroken" refer to?)
Why can't linebroken be used in other contexts?

> Yes and no, for example:
> 
> *This is the maximum of text width*
> ***********************************
> 
> def foobar():
>     if foo and bar and asdf and jkl and fiuu:
>         pass     
> 
> -would perhaps be:
> 
> def foobar():
>     if foo and bar and asdf and jkl 
> and fiuu:
>         pass     
> 
> hmm, not nice. Ok, you might be thinking that this is programming example 
> with bad named variables and not a real case for text writing, really?
> Think for example rst text where you want to keep intending and that is 
> close to previous example.

Here, you need editing: say the point the example intends to make
*before* the example, and it's much easier to follow.

        However, this is a problem for e.g. computer code
        where you want to retain the spacing and indentation.
         
                *This is the maximum of text width*
                ***********************************

        If we blindly break the lines in 
        
                def foobar():
                    if foo and bar and asdf and jkl and fiuu:
                        pass     
        
        we get

                def foobar():
                     if foo and bar and asdf and jkl 
                and fiuu:
                             pass     

Are you implying that we need to be able to say that this is code
and some other text is not, for formatting?

> Shortly thinking xuLink might be a good answer for linking problem

Which linking problem?

> (in 
> structure level you can't link more than one node to one(at least 
> currently (this is not well enough explained!, fyi))). 

Whaaaaat?

> By saing shortly I 
> mean in time. 

Lost me completely.

> For example you have canvasA where is an annotation what is 
> linked to B,C and D (xuLink). You copy the annotation text to another 
> canvasB but all xuLink of course follow. So, now you are not interested 
> about, let's say C and D. How can I unconnect those but keep annotation 
> in canvasA to be right?

You can't - that's what xu linking is about.

> Even association is in canvasA to B, C and D that doesn't implication
> that association with that text should be in canvasB with C and D or even 
> B. With node structure we can change that but with xuLinks we can't, and 
> that implications that xuLinking can't be used.
> 
> So if we can't use xuLinks that implications that we can't use 
> linebreaking with it's current status.

What linebreaking? 

Are you talking maybe about some piece of code we might easily change?

> In posted peg 'canvas_text--mudyc' 

"In the PEG 'canvas_text--mudyc' ..."

> I din't make clear enough all issues 
> close to problems presented in this mail. 


>Basically I wanted to say that 
> we need additional information in structure if we like to work with text 
> not with one note or annotation. Still missing 50% of all issues what I 
> have been thinked but much closer already.

Yes. So we should try to approach these issues bit by bit.

> Issue:
> In discussion with Benja, he saw a big problem in joining nodes, i.e,
> 
> {cat} linked to A and {dog} linked to B
> 
> If we want to join {cat} + {dog} we can do:
>    - join cat and dog to be in one big node and join links.
>        - this causes problems if one want to separate cat from dog
>          because we can't anymore to say if B or A was dog's link or 
>          some otherwise.
>    - join cat and dog next to each other and don't do anything else.
>        - this is equivalent with xuLink style but text is more modifiable.

*OR* make a tree-like supernode.

        Tuomas