This is the mail archive of the
docbook@lists.oasis-open.org
mailing list for the DocBook project.
Re[1]: listitem
- From: "Matt G." <matt_g_ at hotmail dot com>
- To: docbook at lists dot oasis-open dot org
- Date: Sat, 29 Dec 2001 05:14:57 +0000
- Subject: DOCBOOK: Re[1]: listitem
- Bcc:
Sorry I let so much time go by, before getting together my response. For
what it's worth, here it is.
>From: docbook-digest-errors@lists.oasis-open.org
>To: docbook-digest@lists.oasis-open.org
>Subject: docbook-digest Digest #77
>Date: Mon, 03 Dec 2001 08:33:39 -0500 (EST)
>
.
.
.
>From: Norman Walsh <ndw@nwalsh.com>
>To: docbook@lists.oasis-open.org
>Subject: DOCBOOK: Re: listitem
>Date: Mon, 03 Dec 2001 06:34:32 -0500
>
>/ "Matt G." <matt_g_@hotmail.com> was heard to say:
>| I think I've just run into exactly the problem: I have a
>| <variablelist>, but I want to be able to nest more structure
>| inside
>| the <listitem>, for each entry! Here's an sample of the
>| information
>| I'd like to be able to provide about each variable:
>| * descriptive name
>| * type
>| * units
>[...]
>
>Try nested variablelists.
Actually, segmented lists work great -- they're exactly what I wanted!
However, why in the world was it decided that there must there be two or
more <seg> elements per <seglistitem> element?! This seems arbitrary, and
means I can't use it for cases where I have only one of the above properties
list!! I certainly think lists with only one item are reasonable
(especially in the context of automatically-generated content). I realize
that segmented lists are really just tables in disguise, but I don't think
that matters, here.
>| It seems like <fieldsynopsis> gets closer to what I want, but it
>| seems awkward to use as a child of a <variablelist>, since the
>| variable name would need to be specified twice. Furthermore,
>| <fieldsynopsis> doesn't allow me to describe many of the above
>| aspects.
>
>What you're describing doesn't appear to bear any relation to a
>field in a programming language object, which is what
>fieldsynopsis was designed to document.
Actually, what I'm describing are manifested as C bitfield struct elements.
There are properties of these fields, such as "descriptive name", "type",
and "units" that I now have segmented list headings for.
>| Finally, is there any markup (I'm thinking along the lines of a
>| block element) that will allow me to specify a named property?
yup, <segmentedlist> does it, but again, it'd be nice if it would allow only
one <seg> per <seglistitem>.
Matt
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.