This is the mail archive of the
docbook@lists.oasis-open.org
mailing list for the DocBook project.
Re: Re: any reason why a "procedure" is not a child of "para"?
- From: "Robert P. J. Day" <rpjday at mindspring dot com>
- To: Carlos Araya <carlos at cvc dot edu>
- Cc: Jeff Biss <jeff at marco-inc dot com>, David Cramer <dcramer at motive dot com>,docbook mailing list <docbook at lists dot oasis-open dot org>
- Date: Wed, 12 Mar 2003 13:34:49 -0500 (EST)
- Subject: Re: DOCBOOK: Re: any reason why a "procedure" is not a child of "para"?
On Wed, 12 Mar 2003, Carlos Araya wrote:
> Robert:
>
> Semantically iot makes perfect sense but it's when converting the docbook to
> other formats that a problem is caused. How owuld translate the:
>
> <procedure>
> <step>...</step>
> </procedure>
>
> Into HTML or PDF?
>
> I tend to agree with a previous posting where they recomended the reverse,
>
> <procedure>
> <para>Explanation</para>
> <step>Step1</step>
> </procedure>
>
> Adding elements to docbook is not just a matter of saying "Let's add this
> element" but also of developing the transformation to the formats supported
> by the XSL/DSSL stylesheets
i'm just baffled by all of this. as it stands, a <para> is allowed to
contain, as an immediate child element, an <itemizedlist> or an
<orderedlist> or a <variablelist> or a <simplelist> or a
<segmentedlist>.
what is the difficulty in suggesting that it be able to similarly
contain a <procedure>, which is, in effect, just another kind of list?
and how does this make rendering any more difficult? am i just
completely misunderstanding something here?
rday