OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: DOCBOOK: Re[1]: listitem

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>.


Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC