[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 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC