Re: [Gzz] Linked or associated nodes

[Tuomas Lukka]

On Mon, May 12, 2003 at 11:05:22AM +0300, Matti Katila wrote:
> On Sat, 10 May 2003, Tuomas Lukka wrote:
> > On Sat, May 10, 2003 at 09:17:37PM +0300, Matti Katila wrote:
> >>> How exactly must the user be aware where a node ends and another one 
> >>> begins?
> >> No he/she shouldn't be aware. That's the point of all this.
> > No, what I meant is that you imply that some system forces the user 
> > to be aware. What system does that and how?
> 
> pp ;)
>  
> >> All text in the single node? This is the current structure, so what's the 
> >> alternative?
> > Alternative to what you propose. The question is: what really is wrong
> > with the current things. 
> 
> You give a good answer already:
> 
> > Yes, this is part of the intent of the PP links: they're pretty 
> > coarse-grained.


> [...]
> 
> > Why are you convinced that links to buoys need to be from a part 
> > of the node?
> 
> That's the easiest way to implement them :)

???? Doesn't make sense. The easiest way is what we do *now*.

> > There are still more options, if we use something like XHTML inside
> > the nodes: using an XHTML anchor!
>  
> ?

Well, the proposal (currently shelved) of having node content
be XHTML with xu spans.

> > So could we start with listing what exactly we want.
> 
> Benja says that we need xanalogical links and he got me convinced of that.
> Besides, true xanalogical system needs true xanalogical links.
> 
> One problem with xLinks is that user can not do all what he might want to, 
> i.e. you can't do copy/paste on one canvas and try to link the pasted text 
> differently. This is con but not very feasible in sense of what 
> xanalogical links can give us. 

Yes, xu links are one side of the coin, we also do need the structural
links. Xanalogical links link to the content, and structural
links link to its location in a particular place.

> I start listing now:

You should PEG this, as textlinks_initialgoals, or something, I think.
We need to discuss these through.

> Text and placement
> ------------------
> 
> - First of all, text editability. 
> - Important is also spatial placing, so we do like to be able to start 
>   sketching by placing issues around canvas or put list of comments and 
>   ideas next to the main text.

No problem here.

> Linking
> -------
> 
> - Shortly, no limitations. I mean no coarse-grained links, two or more of 
>   links should be able to overlap. 

Umm, now, which type of link do you mean? I think it is conceptually
reasonable to separate xulinks (to content) 
and structural links (to instance).

> - Link visualization should be as noise less as possible. 

What does that mean?

> Formatting
> ----------
> 
> - We like to edit in reStructuredText kind of view but read in generated 
>   view. 

"we"? What kinds of views are these? What's the generated view?

Lots of definitions missing.

> - We don't like to see formatting as a part of the text (say, html tags 
>   or TeX {} ) but if copying formatted text it should appear as it was 
>   formatted.

You just said we edit in reStructuredText kind of view???

> Copy/paste
> ----------
> 
> - Formatting should follow.
> - Links should follow, although we should be able to say that we 
>   don't want some of the links (something like 'close document' as Benja 
>   proposed in irc) or if we do want more to appear.

Ok.

> Misc
> ----
> 
> - rdf structure for paragraphs and sentences (and even words)? This 
>   might lead to better text editability.

No, this is not appropriate for the "what do we want" -level discussion.
Let's leave implementation till later.

        Tuomas