Re: [Scrollkeeper-devel] Category Trees

[Dan M. <d-...@uc...>]

On Fri, 24 Nov 2000, Laszlo Kovacs wrote:

> How do we deal with category trees? I see category trees as generic
> empty content lists.
> 
> These are the possibilities we discussed:
> 
> 1. Enforce a category tree and ignore all docs that don't fit into it.
> 2. Enforce a tree and put all docs that don't fit into an Other section
> of the Content List.
> 3. Supply a tree (installed) and OMF files come with new categories,
> extend the Categories in the Content List with them (don't modify the
> category tree).
> 4. Recommend a set of categories on the project web site, but don't
> supply any tree. Build the content list(s) from whatever comes in the
> OMF files.
> 5. Don't recommend any categorization, but keep support in the OMF files
> to specify categories. Extend the Content List with whatever comes in
> the OMF files.
> 
> 1. and 5. are there for completeness only. I suppose nobody thinks they
> would be a way to go.
> 
> So what do people think? Which is the best way to do it? Any other
> ideas?

One more:
6) Support more than one of the above and allow the user/SA to decide
which one method is employed in /etc/scrollkeeper.conf or
$HOME/.scrollkeeperrc.

One other issue which should be discussed for options #1-#3 - What do we
do with empty parts of the tree?  Do we show branches that don't have
documents in them?  Or are these branches only created as they get
populated?   I think the assumption right now is that empty branches
exist and are passed to the browser.  (The browser could still potentially
snip them out.)

And another issue: If we have a categories tree, should we allow the user
to specify in the conf file which tree to use?  Presumably one may want to
use an alternate tree, such as a subset of the recommended tree.  For
example, a user might copy the default tree into
$HOME/.scrollkeeper/categories.xml and then chop out the man and info
page sections.

Dan