Re: DOCBOOK-APPS: Re: mixing section elements

[Roel Vanhout <roel@riks.nl>]

The chunking you describe is exactly what I've been trying to achieve 
the past week(s), at first I had the first order you describe but I was 
advised to do it like in your second example; the reasoning was like you 
say. Anyway, it would be useful (for me at least :) ) if this change was 
made; do I need to put in an RFE for this?

cheers,

roel


Jeff Beal wrote:
> I would think that 
> 
> | <chapter>
> |    <title>Example title</title>
> |    <sect1><para>Test para</para></sect1>
> |    <simplesect><para>Another test para</para></simplesect>
> | </chapter>
> 
> would really mess up the chunking.  Where would the simplesect be chunked if
> you were chunking the <sect1/>?  Thinking in terms of chunking only, 
> 
> | <chapter>
> |    <title>Example title</title>
> |    <simplesect><para>Another test para</para></simplesect>
> |    <sect1><para>Test para</para></sect1>
> | </chapter>
> 
> would provide better results.  This way, authors can have a few
> "simplesect"s worth of data included with the chapter, and the actual
> "section"s are chunked out according to the standard chunking parameters.
> 
> Just my two bits worth.
> 
> Jeff Beal
> 
> -----Original Message-----
> From: Norman Walsh [mailto:ndw@nwalsh.com]
> Sent: Thursday, January 23, 2003 9:01 AM
> To: Roel Vanhout
> Cc: docbook-apps@lists.oasis-open.org
> Subject: DOCBOOK-APPS: Re: mixing section elements
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> / Roel Vanhout <roel@riks.nl> was heard to say:
> | the moment) Arbortext's Epic editor to edit the document, and it
> | complained that <simplesect> was out of context when it's parent node
> | also had <sect1> or <section> elements, eg like this:
> 
> You can't mix section types. They form a strict hierarchy.
> 
> | <chapter>
> |    <title>Example title</title>
> |    <sect1><para>Test para</para></sect1>
> |    <simplesect><para>Another test para</para></simplesect>
> | </chapter>
> 
> It might be reasonable to allow that, although I would always want to
> prohibit
> 
>  <chapter>
>     <title>Example title</title>
>     <sect1><para>Test para</para></sect1>
>     <section><para>Test para</para></section>
>  </chapter>
> 
> and
> 
>  <chapter>
>     <title>Example title</title>
>     <sect1><para>Test para</para></sect1>
>     <simplesect><para>Another test para</para></simplesect>
>     <sect1><para>Test para</para></sect1>
>  </chapter>
> 
> | I also couldn't add a <simplesect> element as a sibling to a <sect1>,
> | <sect2> or <section> element through Epic's GUI.
> | I looked through the documentation (tdg) and looked at the content
> | model of chapter, and although I'm not an expert at reading dtd's, it
> | looks like my example should be valid. Now, the dtd that Epic uses is
> | that for DocBook 4.0; has this changed in the mean time? Did I read
> | the content model wrong? Any hints? Thanks!
> 
> You can do this:
> 
>  <chapter>
>     <title>Example title</title>
>     <sect1><para>Test para</para>
>       <simplesect><para>Another test para</para></simplesect>
>     </sect1>
>  </chapter>
> 
>                                         Be seeing you,
>                                           norm
> 
> - -- 
> Norman Walsh <ndw@nwalsh.com>      | One of the great misfortunes of
> http://www.oasis-open.org/docbook/ | mankind is that even his good
> Chair, DocBook Technical Committee | qualities are sometimes useless to
>                                    | him, and that the art of employing
>                                    | and well directing them is often
>                                    | the latest fruit of his
>                                    | experience.--Chamfort
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>
> 
> iD8DBQE+L/WYOyltUcwYWjsRApKNAJ0Raz/BpT1US2D3Sku9iPAYUwqFDgCfauT1
> c5dHE0pV1kq3PKceidA/nPY=
> =qcTJ
> -----END PGP SIGNATURE-----