[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: FURTHER Clarif. re inside/contents
- To: zzdev@xxxxxxxxxx
- Subject: Re: FURTHER Clarif. re inside/contents
- From: Mark-Jason Dominus <mjd@xxxxxxxxxx>
- Date: Wed, 28 Oct 1998 10:52:50 -0500
- In-reply-to: Your message of "Wed, 28 Oct 1998 18:18:19 +0900." <22.214.171.124.19981028181819.007944c0@xxxxxxxxxxxxxxxxxxx>
- Reply-to: zzdev@xxxxxxxxxx
> >> The expected structures is:
> >> d.contents \/ d.inside => ("|" here means "no connection)
> >> A a
> >> b
> >> c
> >> B d
> >> e
> >> f
> >> where for some reason (probably visual convenience in
> >> some context), A *might* be connected to B, abd c to d,
> >> but those connections have no system-supported connection.
> >Maybe I misunderstand your illustration, but if c and d are connected,
> >won't the system interpret d, e, and f as part of the contents of A?
> Thought I said it Implicitly !-) Answer is that the system
> *must stop* thinking the further items posward on d.contents
> are on the list *when it encounters the countervailing B*.
The vertical direction here is `d.contents'. If the user doesn't want
d to be part of the contents of A, the answer is simple: Don't link c
If c is linked to d, that should express something different from c not
linked to d. But you are saying that regardless of whether or not the
link is there ZZ will treat it the same way, as if there was no link.
Why should it do that? If the user makes a link, it's not because
they want ZZ to ignore it.
If ZZ does that, it is taking the power of expression from the user by
assigning the same meaning to the presence and absence of a link.
(``Sorry, you are no longer allowed to use the word `red'.'')