Bob Stayton wrote:
tables, admonitions, lists, etc. (but not para). I'm sure there were good arguments at the time for such a design, but I have never liked it. The simpara element (simple para) was created for those who don't want such a structure. The simpara element does not allow other block elements, only inline elements.
For my customers, I usually redefine para to have the same content model as simpara to remove complexity of nested block elements:
# model para after simpara (no nested blocks, no info)
db.para =
element para
{
db.simpara.attlist,
db.all.inlines*
}
But some people prefer to use nested blocks, for example if you have let
say enumeration presented as list inside one logical piece of text, you
it is more precise to markup it as:
<para>
...
<itemizedlist>
...
</itemizedlist>
...
</para>
then as
<para>
...
</para>
<itemizedlist>
...
</itemizedlist>
<para>
...
</para>
But personally I'm usually using the later variant too.
Jirka
--
------------------------------------------------------------------
Jirka Kosek e-mail: [EMAIL PROTECTED] http://xmlguru.cz
------------------------------------------------------------------
Professional XML consulting and training services
DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------
signature.asc
Description: OpenPGP digital signature
