[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook] How to display a directory tree
On Wed, Apr 20, 2005 at 02:06:33PM -0400, Stefan Seefeld wrote: > > I wonder if there is a set of tags to represent a directory tree, with > > the files included. The main purpose is for system administrators who > > want to explain where some file are, and to give an explanation for > > each file. > I have used 'tree' in combination with <screen> to do that. What is this 'tree' you speak of? As for myself, I've used nested variablelists to achieve this sort of semantics. I treat each varlistentry as a directory entry, the (first) term in a varlistentry as the name of the entry, and the listitem as a description and an optional further directory expansion (using the same variablelist structure). For example: <variablelist> <varlistentry> <term>usr</term> <listitem> <para>Common directory for shared user resources on UNIX systems.</para> <variablelist> <varlistentry> <term>bin</term> <listitem> <!-- etc... --> </listitem> </varlistentry> </variablelist> </listitem> </varlistentry> </variablelist> I haven't messed with the formatting, but I can imagine how one could format this in a number of ways to look like a directory list. Upon reflection, it seems reasonable to me to specify the role attribute for such variablelists (role="directoryList") or somesuch. Alternatively, this may be a lot cleaner with a standard itemizedlist or simplelist when used with the new term definition structure in DocBook-NG[0] [1]. Tangentially, this brings up a slight nit that I have with DocBook. I think that the variablelist element is misnamed. I think the idea of the "definition list" that is present in HTML is a closer fit to the common uses of this type of list. In a hypothetical definition list, one could still "define" variables (and so we can still represent variable lists), but we can also "define" anything that requires defining (such as the structure of a directory in this case). But of course, such a change would be Significantly Backwards Incompatible(tm). Take care, John L. Clark [0] http://norman.walsh.name/2005/04/08/jagermeister#p13 [1] http://lists.oasis-open.org/archives/docbook/200502/msg00042.html
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]