Re: DOCBOOK: Re: New element for Step alternatives?

[Michael Smith <smith at xml-doc dot org>]

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