Re: [Gzz] Linked or associated nodes

[Matti Katila]

On Mon, 12 May 2003, Tuomas Lukka wrote:
> On Mon, May 12, 2003 at 11:05:22AM +0300, Matti Katila wrote:
>> On Sat, 10 May 2003, Tuomas Lukka wrote:
>>> 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*.

Misunderstandindg in here from my side. Yes, current is the easiest way.


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

This leads that two overlapping links can't be maid as it is possible with 
xulinks or can tags overlap?


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

Structural links are so hard to define. It may seen easy at first level 
and pp kind of stuff is doable but limitations seem to run in place with 
hurry. If you are intended to write even more than one sentence or want 
to link the sentence partly or...
 
>> I start listing now:
> You should PEG this, as textlinks_initialgoals, or something, I think.
> We need to discuss these through.

I haven't been able to write one accepted peg so I need to keep 
practising of writing first =)


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

Both, but I can accept that structural links don't do that or do that by 
kludge. At least I don't want to see handful of text and all I can do is 
link that big piece with links. It's like in an article the refs(links) 
are usually placed around the whole text. If you keep all text in one node 
you can't make links from here to there as a part of text.

 
>> - Link visualization should be as noise less as possible. 
> What does that mean?


For example(structural link, splitted nodes; same goes with xulinks):

  node: { This is test. }   and link that to somewhere.

Uups, there's error in writing, so if splitted:

  nodes: { This is } { a } { test. }

Two "same" link { This is } and {test. } nodes are very close to each 
other so it might not be very good to put two connecting lines for them 
if one is enough. 

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

I want, that's reason enough ;)

> What kinds of views are these?

Just the orginal canvas view. Start from annotation and stop there or keep 
writing to a whole book. 

> What's the generated view?

Where rst text is poisoned with XHTML tags and such but it looks good.

> Lots of definitions missing.

Error 123, system overloaded.


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

Yes? I think you misunderstood something from my explanation.

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

Ok