This is the mail archive of the
docbook@lists.oasis-open.org
mailing list for the DocBook project.
Re: Re: New element for Step alternatives?
- From: Michael Smith <smith at xml-doc dot org>
- To: Bob Stayton <bobs at caldera dot com>
- Cc: docbook at lists dot oasis-open dot org
- Date: Thu, 05 Dec 2002 06:21:46 +0900
- Subject: Re: DOCBOOK: Re: New element for Step alternatives?
- References: <200209132023.g8DKN6g11843@purol.East.Sun.COM><87ofa19f5b.fsf@nwalsh.com> <20021015122933.GA11751@sideshowbarker><87r8dpdsp1.fsf@nwalsh.com> <20021118144515.GA11830@sideshowbarker><87n0o5tuyw.fsf@nwalsh.com> <20021119175750.GA12190@sideshowbarker><20021121203406.A15958@caldera.com>
Hi Bob,
Sorry for the ellisions, but I want to reply about a couple of
specific points.
You wrote:
> I also thought that Mike's suggestion for a generalized step
> container would be useful. Then I realized that we already
> have a container for steps: procedure.
But that's not true.
Earlier in your message, you wrote that the content model of
the Procedure element looks like this:
> procedure = ([front stuff], step+)
> So I'm agreeing with part of Norm's suggestion, to change
> the content model of step to replace (substeps) with
> (substeps|stepalternatives). And the content model for
> each of substeps and stepalternatives would be simple:
>
> (step+)
Substeps and the proposed Stepalternatives are containers for
steps. What I'm suggesting is that we add a parallel generalized
step container, with the same simple (step+) content model, for
wrapping sets-of-steps-that-aren't-substeps.
The current Procedure is not that. There's a huge difference
between the Substep and Procedure content models -- namely, the
[front stuff] you mention above.
That front stuff, if you write it out, amounts to quite a bit of
stuff:
procedure ::=
(blockinfo?,
(title,titleabbrev?)?,
(calloutlist|glosslist|itemizedlist|orderedlist|segmentedlist|
simplelist|variablelist|caution|important|note|tip|warning|
literallayout|programlisting|programlistingco|screen|screenco|
screenshot|synopsis|cmdsynopsis|funcsynopsis|classsynopsis|
fieldsynopsis|constructorsynopsis|destructorsynopsis|
methodsynopsis|formalpara|para|simpara|address|blockquote|
graphic|graphicco|mediaobject|mediaobjectco|informalequation|
informalexample|informalfigure|informaltable|equation|example|
figure|table|msgset|procedure|sidebar|qandaset|productionset|
constraintdef|anchor|bridgehead|remark|highlights|abstract|
authorblurb|epigraph|indexterm|beginpage)*,
step+)
In a doc instance, any and all of that front stuff can occur, any
number of times, before you actually get to the steps. In a
rendered document, you could actually have *pages* of content --
graphics, notes, equations, lists, tables -- before you get to the
actual steps in the Procedure. There's nothing necessarily wrong
with that -- it's just that it becomes hard to think of or
describe Procedure as a container for steps, because, yeah, while
it does contain steps, it can also contain whole lots of other stuff.
So what I think is needed is a wrapper just for steps that has a
content model parallel to the Substeps wrapper. That would allow a
user to logically mark up/isolate the set of steps in the
Procedure, as a group -- and allow a processing application to
easily automatically separate out just the set of steps, as a
group, from the rest of the stuff in the Procedure.
The fact that two or more steps in a row, by themselves, form a
logical division -- a group of steps -- is something that I think
ought to be expressible/capturable through markup, and so through
a content model in the DTD. The current Procedure content model
does not not make it possible to express or capture that logic.
But a Steps container with a (step+) content model would.
--Mike