[pmwiki-users] hierarchical groups, revisited

[Américo Albuquerque]

----- Original Message -----
Subject: Re: [pmwiki-users] hierarchical groups, revisited
Date: Thu, 25 May 2006 09:51:24 -0500
From: "Patrick R. Michaud"

 > On Thu, May 25, 2006 at 02:52:17PM +0200, Joachim Durchholz wrote:
 > > > But let's go back to the original example of a "relative link" --
 > > > [[Canine/StBernard]]. In fact, let's just look at a link called
 > > > [[Canine]] from within the Animal.Canine.Beagle page. If
 > > > we _strictly_ follow the pattern above, then [[Canine]] within
 > > > the Animal.Canine.Beagle page ought to link to Animal.Canine.Canine.
 > >
 > > So the link is wrong. Borrowing from filesystem path syntax, the 
link to
 > > the parent category would have to be written as [[..]].
 >
 > "Parent category"? Beagle is in the Animal.Canine group. I'm
 > trying to link to the "home of the current group". Using [[..]]
 > to mean "current group's home" seems totally wrong.
For what I've seen it would be more logical to use [[./$GroupPage]] for 
the home of the current group. Using the filesystem aproach it would be 
[[./]]

(...)
 > To summarize what I think you're saying above:
 >
 > - sibling: to go from Animal.Canine.Beagle to Animal.Canine.Terrier,
 > use [[Terrier]]
 > - parent: to go from Animal.Canine.Beagle to Animal.Canine, use [[..]]
 > - uncle: to go from Animal.Canine.Beagle to Animal.Feline, use 
[[../Feline]]
 > - child: to go from Animal.Canine to Animal.Canine.Terrier, use 
[[./Terrier]]
 >
 > Note that this last one is quite contradictory to what people
 > expect from dealing with filesystems and urls. For example, if
 > I have a web page at "/foo/bar", and that page contains a link
 > to "./xyz", then the link targets "/foo/xyz" and not "/foo/bar/xyz".
 > In other words, in filesystems and urls, "./xyz" is a sibling link
 > and not a child link.
Personaly, I feel that, for relative links, we would use the namespace 
convention (as in XML)

- home of current group (that would be a sibling): [[./]] or 
[[sibling:]] using the namespace syntax
- sibling: [[sibling:Terrier]] or just [[Terrier]] as is used now
- parent: [[parent:]]. The [[..]] could also work fine here
- uncle: [[parent:Feline]]. The [[../Feline]] could also do
- child: [[child:Terrier]]. the [[./Terrier]] syntax if very confusing 
and will led to misleading results

 > Personally, I think that sort of subtle dissonance between url
 > syntax and PmWiki hierarchical page syntax could be hard for
 > many to swallow.
 >
 > > The root of the confusion is that the filesystem analogy breaks 
down at
 > > this point. In a file system, a directory doesn't double as a file; in
 > > PmWiki, a group doubles as a page.
 >
 > Exactly.
Not so for urls. Using /somedir is the same as doing 
/somedir/index.html. The same can be said about the PmWiki groups, 
/Group would be the same as saying /Group/$GroupPage (whatever the 
$GroupPage is). In a hierarchical page you would simply have a Group 
named Animal that would have to have a homepage defined, be it Animal, 
HomePage or any other name. [[Animal]] in it's sibling pages would 
actually lead to [[Animal/$GroupPage]]

 >
 > > I'd suggest a format like this:
 > >
 > > Absolute link:
 > > Link to parent:
 > > Link to sibling:
 > > Link to child:
 >
 > I like this discussion format very much. But if we're really
 > discussing relative link syntax for hierarchical groups, we also
 > need "Link to uncle" (link to sibling of my parent) and
 > "Link to cousin" (link to child of a sibling of my parent).
 > Without a way to support relative links to uncle and cousin pages,
 > PmWiki's current "flat" scheme can be made to act equivalently
 > to a hierarchical one.
 >
So, my proposal would be
Absolute link: [[/Animal/Canine]]
Link to parent: [[parent:]] or [[..]]
Link to sibling: [[sibling:Feline]] or [[Feline]]
Link to child: [[child:Bulldog]]
Link to uncle: [[parent:Vegetal]]
Link to cousin: [[parent:Vegetal/Tree]]

We could also have several layers with namespaces using the '.' 
notation, like [[parent.parent:]] to get the granparent from Buldog and 
a parent's sibling could be accessed by [[parent.sibling:Feline]], a 
granparent sibling by [[parent.parent.sibling:Vegetal]], etc.

(...)
 > > Actually the semantics is easy. What's problematic is finding a syntax
 > > that has all of these properties:
 > > 1) Easily understood (i.e. close to existing syntax),
 > > 2) can differentiate between sibling and child links,
 > > 3) offers display variants (absolute path vs. just the last 
component of
 > > the path vs. path as given in the link), and
 > > 4) is backwards compatible with current wikilink syntax.
 > >
 > > I don't think that (2) and (4) are compatible. I suspect that any 
syntax
 > > that supports both would be too irregular and ugly to live.
 >
 > I think we should first figure out how things ought to work
 > w/o backwards compatibility, and then we could potentially
 > deal with migration issues.
 >
 > > (2) is difficult to reconcile with (1), simply because there's no
 > > precedent in filesystem syntax for this.
 >
 > Exactly. And I think filesystem syntax is too widespread and
 > too far ingrained in the web itself for us to be able to dismiss it.
Yes but there is some similarity with XML namespace syntax. XML elements 
can have both  text (act as a page) and childs (act as a group)

Americo Albuquerque