gzz-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gzz] Linked or associated nodes


From: Matti Katila
Subject: Re: [Gzz] Linked or associated nodes
Date: Mon, 12 May 2003 11:05:22 +0300 (EEST)

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 :)
 
> There are still more options, if we use something like XHTML inside
> the nodes: using an XHTML anchor!
 
?
 
> You're proposing mechanisms to do something before you say what
> the something you *want* to do is.

Yes, that's true ,)

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


I start listing now:

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.


Linking
-------

- Shortly, no limitations. I mean no coarse-grained links, two or more of 
  links should be able to overlap. 
- Link visualization should be as noise less as possible. 
  

Formatting
----------

- We like to edit in reStructuredText kind of view but read in generated 
  view. 
- 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.


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.


Misc
----

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


   -Matti

 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]