OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

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

  procedure ::=

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC