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