Fwd: [Trac] Tags
Muness Alrubaie
muness at gmail.com
Thu Jan 6 16:01:47 EST 2005
Replied to Alexey alone by mistake. Forwarding to the list as well.
---------- Forwarded message ----------
From: Muness Alrubaie <muness at gmail.com>
Date: Thu, 6 Jan 2005 15:43:12 -0500
Subject: Re: [Trac] Tags
To: Alexey Shamrin <shamrin at gmail.com>
On Thu, 6 Jan 2005 13:53:56 +0300, Alexey Shamrin <shamrin at gmail.com> wrote:
> Hello Muness!
>
> 1. Regarding tag vs label vs category I will agree with Christopher
> that adding an option
> here and there is not an option %-) It's better to be consistent.
Fair enough.
>
> 2. Maybe it'll be better to replace "/" with ":" as a separator
> (Wikipedia uses this in some places. For example Help:Contents). It
> will make it clear that wiki hierarchies is not the same that
> hierarchical URLs. And using ":SubPage" to denote the subpage of the
> current wiki page is somewhat clearer than "/SubPage" (confusing with
> top-level) or "./SubPage" (confusing with the file in current
> directory as in Unix), I think.
>
> Or you can use ":" to denote the subpage and still use "/" as a separator:
>
> :SubPage/SubSubPage/GoingDeeper
I like the ":" syntax. It's quite intuitive to me.
>
> (but this is little inconsistent).
>
> 3. How about merging the concept of tag and hierarchy? For example, I
> tag ExamplePage
> with IndexTag. Now IndexTag/ExamplePage (or Index:ExamplePage)
> automatically becomes the synonym of IndexTag. Of course ExamplePage
> can also be tagged with SuperTag giving automatic
> SuperTag/ExamplePage.
>
> This way you can throw away ListTags. And your examples:
>
> [[ListTags(COMP313)]]
> [[ListTags(COMP313,Week1)]]
>
> become (must be implemented in Trac, of course):
>
> COMP313/*
> Comp313/Week1/*
>
> or
>
> COMP313:*
> Comp313:Week1:*
This would be great. For my implementation I didn't want to patch
Trac. This is for multiple reasons:
1) I didn't know if my patches would be accepted into Trac and didn't
want to reimplement when the next release came out.
2) textdriven.com is a managed hosting solution and it would've been
difficult to use my own branch of Trac.
I actually considered making TagIt implicitly tag the hierarchical
parent of a wiki entry. This would achieve this merging of concepts.
I think.
One note though. Your conversion of the examples isn't quite right:
COMP313% matches COMP313 and COMP313:*. If the union operator is
implemented in TitleIndex this would be fine. The solution would be
TitleIndex(COMP313 union COMP313:*) with some more appropriate syntax,
of course.
>
> 4. Another thing that just came to my mind is the concept of top-level
> tag (can be denoted
> as "/" for example). Essentially all wiki pages in current
> implementation of Trac are implicitly tagged under top-level tag. If
> #3 will be implemented it will become explicit and one will have the
> ability to untag the page from top-level and leave it somewhere else.
Yes, yes, yes! Following this idea, a wiki page in a tag can refer to
other pages in the same namespace directly. If they are however, not
in the same namespace, then you have to give a full path. e.g. Given
1) Top1/SubPage1/SubSubPage1/GoingDeeper1
2) Top1/SubPage1/SubSubPage1/GoingDeeper2
Top1/SubPage1/SubSubPage1/GoingDeeper1 can reference
Top1/SubPage1/SubSubPage1/GoingDeeper2 by just saying GoingDeeper2.
If it wanted to access Top2/SubPage1/SubSubPage1/GoingDeeper2, it'd
have to specify the whole path.
Right?
(This is why I like the terminology "overlapping namespaces" instead
of tag or label...)
>
> Alexey
>
Muness
--
See my blog at http://muness.blogspot.com
--
See my blog at http://muness.blogspot.com
More information about the Trac
mailing list