[dokuwiki] Re: Purple Numbers

On Tue, 19 May 2009 21:29:13 +0100
Anika Henke <anika@xxxxxxxxxxxxxxx> wrote:
> 
> isn't.
> Your example "linux:driver#usb.configuration.2:3" assumes that any 
> *first level headline* gives the first part of the ID. What about
> pages  that have no first level headlines? And the IDs won't look much
> better,  just because there is the first headline in front instead of
> 'HID'. You  might have thought about using more levels. But where
> should we stop?
> 
> In the following example, what should the ID for the first paragraph
> in  dogs' behaviour be?
> 

Okay, I see where the current section IDs diverge from HIDs. The link to
the dogs' behaviour section would be #behaviour1, but that's not
hierarchical. Even though <sectionid>:<pnode> can describe every
paragraph.

Andi mentioned purple numbers being stable. But numbers alone aren't
stable with insertion. Adding Bears like so...

====== Animals ======
===== Mammals =====
==== Carnivores ====
=== Cats ===
== Physiology ==
== Behaviour ==
=== Bears ===
== Physiology ==
== Behaviour ==
=== Dogs ===
== Physiology ==
== Behaviour ==
==== Primates ====
===== Fish =====

Invalidates all the references to dogs and its sub-sections. If precise
readability isn't a concern, an abbreviated heading may suffice. 
 1. Strip stop-words and non-letters from the title.
 2. If the title is empty, use '_'.$nodeid
 3. else utf8_substr($title,0,2).(utf8_strlen($title)-2)
 4. disambiguate with extra digits

IDs would all be \w+\d+ so they can be joined directly. Then add the
':'.$pnid

#an5ma5ca8do2be7:1

Or if the purpose is to coordinate changes on a multilingual wiki, then
obviously the content of the sections must be ignored. In which case
I think the current system is the most practical. The insertion problem
becomes less important because the IDs would be tied to each revision.

> I have read before that many purple number implementations take nested
> lists into account. But I couldn't see the point of it. Well, okay, I 
> could see the general point, but didn't find it important enough to 
> implement it.
> If you (and others?) feel strongly about this, I can implement it.
> 

Perhaps not nested lists. That would just create unnecessarily long IDs.
But adjacent list blocks should be enumerated separately, I think.

 - Item 1 (:1.1)
 - Item 2 (:1.2)
   * Item 2, sub-item 1 (:1.3 not :1.2.1)

 - Item 1 of second list (:2.1)

Adding a third item to the first list won't change the second
list.

-- tom
telliamed@xxxxxxxxxxxxx
-- 
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Other related posts: