This is the mail archive of the docbook@lists.oasis-open.org mailing list for the DocBook project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Re: any reason why a "procedure" is not a child of "para"?


As I see it now you have a point in seeing that the procedure element be included as a child of the paragraph element. It does make sense, especially in context of the other child elements. Why not put in an RFE at: http://sourceforge.net/projects/docbook/?

Jeff

Robert P. J. Day wrote:
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






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]