[ruby-talk:00918] Re: RDtool-0.5.0

At first, I have to say what I've written on labels/references is
implicitly supposing context-dependency, which is similar to scope
rules and hierarchical namespaces seen in many programming languages.
Sorry.


In message <[e-mail]>
[e-mail] writes:

> How can we distinguish in situation like following example?
> 
> = Foo
> : Quux    <--- 1
> 
> == Quux   <--- 2
> 
> : Foo
>    : Quux <--- 3
> 
> Which label is refered by ((<Foo::Quux>))??

Well, 1 and 2 are not distinguishable even with my assumption.... Hmm,
we can vary namespace separators for Chapter/Section headings and
DescList's ones, say, ((<Foo/Quux>)) for 1 and ((<Foo::Quux>)) for 2.

# ((<Foo::Quux/Foo/Quux>)) for 3, if it is referred from out of Chapter
# Foo.


However context-dependency is already too complex to `easy to write'
document/program.  And the proposal above may lead us to more
confusion.  Not so good :-<


> > Well, `::' is merely one of candidates.  However some kind of
> > hieralchical naming/referencing scheme should be supported to
> > avoid conflict between anchors.  Otherwise we cannot apply RD to
> > long documents which contain a number of similar format parts,
> > such as manuals of class library or OO frame work.
> > 
> > .... But user level efforts are always available.  Writers can
> > give unique hieralchical name to chapters, sections, DescList
> > items and so.  Uh hum.  It may be true, but I dislike such a way.
(cut)
> So, if we put 2 or more classes into 1 file, we must use titles like
> "Constants of Foo" for Headline.

`User level effort' means this, and `It may be true, but I dislike
such a way' too.


> Ofcourse, I want to write such like:
>   = Foo
>   == Constants

And refer with some form like ((<Foo::Constants>)) from anywhere.
Namely, `Hierarchical referencing scheme should be supported'.  Of
course it is more desirable that ((<Constants>)) can be used in the
Chapter/Section Foo.

# Yes, not `hieralchical' but `hierarchical' :-P


-- 
[e-mail]                              November 10, 1999
Abstract should not be abstract.