So to maintain the current functionality of the stylesheets I'd need to add a
processing instruction to all of the simplesect elements in all of my content?
That seems like a lot of work.
I'd still ask for simplesect chunking to be parameterized, but if if the
community feels that simplesect should chunk like regular sections then so be
it.
-Original Message-
From: David Cramer [mailto:[EMAIL PROTECTED]
Sent: Mon 9/15/2008 6:28 PM
To: Johnson, Eric; docbook-apps
Subject: RE: [docbook-apps] should simplesect be chunked?
I had noticed that simplesects don't chunk a while back when some of our
writers wanted a way to create sections that don't chunk and simplesect
seemed a possible answer. I was worried though that it was a bug that
would be fixed someday :-) So I implemented to
let writers control where chunking stops and that's now part of the
xsls.
I don't have strong feelings about simplesects chunking since we use the
processing instruction. I can obviously understand the need for giving
writers the option of creating sections that don't chunk. I do think
that either simplescts should chunk or "The Definitive Guide" should be
updated to indicate that the processing expectation is that they don't
chunk (or it should be parameterized). The current processing
instruction will stop the chunking of simplesects too btw.
David
> -Original Message-
> From: Johnson, Eric [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 15, 2008 1:28 PM
> To: docbook-apps
> Subject: RE: [docbook-apps] should simplesect be chunked?
>
> Bob,
> I do not disagree with your position in theory. I can see
> where there may be style guides that use simplesect in such a
> way as they would be long enough to warrant entire html pages.
>
> I don't think that having simplesect blocks being that long
> makes much sense however. We use simplesect as the only
> terminal section element.
> It is, in information mapping terms, a block. So a chapter
> would never only have sect1 elements breaking it up into
> sections. Such a chapter would use simplesect. If the
> simplesect blocks get big enough to warrant it, then the
> chapter would need to be broken up into sections - each of
> which contains a group of simplesect element. sect1-sect5
> elements and section elements are not used as terminal sections.
>
> Since this is only one way of doing the mark-up using docbook
> and others will likely disagree with this approach, I don't
> think adding the capabilities to chunk simplesect is a bad idea.
>
> Perhaps simplesect chunking should have its own parameter for
> being turned on and off? That way people whose output depends
> on the current chunking algorithm for sections won't be messed up.
>
> Cheers,
> Eric
>
> -----Original Message-----
> From: Dave Pawson [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 15, 2008 1:54 PM
> To: Bob Stayton
> Cc: DocBook Apps
> Subject: Re: [docbook-apps] should simplesect be chunked?
>
> Bob Stayton wrote:
> > Hi,
> > I don't think section level is the right criterium for excluding
> > simplesect from chunking. A chapter can contain nothing but
> > simplesect elements, making them equivalent to level1 sections.
> > Currently such a chapter would be a single chunk, even if each
> > simplesect was long, leading to a very long chunk. Also, in the
> > chunking stylesheets, the level of section chunking is
> controlled by a
> stylesheet parameter.
> >
> > So you could have one chapter consisting of simplesects that is are
> > not chunked, and another chapter consisting of single-level section
> > elements, and only the latter chapter will be chunked.
>
>
> Too many what-if's there Bob. We can all make daft decisions
> when marking up.
>
> For Docbook, used sensibly, there's no need to chunk at
> simplesect level IMHO.
>
>
>
> regards
>
> --
> Dave Pawson
> XSLT XSL-FO FAQ.
> http://www.dpawson.co.uk
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
