This is the mail archive of the
mailing list for the DocBook project.
Re: [docbook] How to display a directory tree
Thank you very much for this quite detailed reply.
I agree that variablelist is strangely named. For instance I usually use
it in <refentry> sections to explain the use of the options supported by a
command line utility.
On Wed, 20 Apr 2005 11:45:58 -0700, John L. Clark <email@example.com> wrote:
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:
<para>Common directory for shared user resources on UNIX
<!-- etc... -->
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
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).
John L. Clark
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com