Re: [Gzz] Linked or associated nodes

[Tuomas Lukka]

On Mon, May 12, 2003 at 12:21:47PM +0300, Matti Katila wrote:
> >>> 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?


Well, I for one am not at all convinced that structural links need
to be able to overlap. Please convince me.

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

No, they're easy to define: they link to a particular location, 
an instance, instead of the permanent media.

However, their exact design raises a lot of issues with different
tradeoffs.

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

Actually, what you wrote is almost complete, bar arguing. We just need
to document 

1) what the names are (xulinks, structural links)

2) what features we want (overlapping links or not, ...)

in one place.

Just cut&paste your email and you're half done. The reason for no PEGs yet
being accepted is that you've always started at the corner of some really
big issues and then we can't accept the PEG before resolving the issues
(like here).

+ of course the list of issues and the reasons they were resolved
like they were.

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

Another possibility is not linking text but to put in explicit anchor
objects, analogous to the [42] in articles. This has several things 
in its favour, actually, as it gets rid of a lot of problems.


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

Ok, that should be in the example in the PEG.
Of course, my previous suggestion takes care of that as well!

> >> Formatting
> >> ----------
> >> 
> >> - We like to edit in reStructuredText kind of view but read in generated 
> >>   view. 
> > "we"?
> 
> I want, that's reason enough ;)

Don't say "we" then, at least before defining the view ;)

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

How is rst text ever poisoned with XHTML tags.

You need to explain these two view types from first principles, as
it seems you have a good idea of what they are but that's not at all
conveyed to us, poor readers.

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

You explanation was the error 123 which didn't help too much...
You really need to *define* what views you are talking about.

What does the user see in each case?

        Tuomas