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

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

Norman Walsh <ndw@nwalsh.com> writes:

> / Michael Smith <smith@xml-doc.org> was heard to say:
> | Norman Walsh <ndw@nwalsh.com> writes:
> |
> |> I'm trying to recap where we stand on this proposal.
> |> 
> |> There seems to be general agreement that it's a good idea. The
> |> question is, exactly what should the markup look like?
> |
> | I think there are some shortcomings in Procedure that we probably need
> | to address. But rather than going at it piecemeal, I'd like to suggest
> | that we consider taking a look at the Procedure model as a whole, and
> | deal with coming up with revisions that will address not just the lack
> | of "choice" markup and the more recent "Task" proposal that Sabine
> | submitted, but other potential changes that might be worthwhile.
> 
> It's been some time since this was posted and there hasn't been a lot
> of discussion. Some more comprehensive "task" markup might be a good
> idea, but I'd like to see some concrete proposals.
> 
> In the meantime, we've got two issues on the table that have been
> lingering. It seems to me that we can either abandon them, try to find
> simple solutions for them, or leave them lingering while we
> investigate some larger design options.
> 
> Personally, I'm inclined to the middle course. To wit:
> 
> * Add alternatives to procedure as I suggested previously:
> 
>     Replace 'substeps' in step with (substeps|stepalternatives)
>     Both substeps and stepalternatives contain (step+). For substeps,
>     the processing expectation is "choose all, in the specified order".
>     For stepalternatives, the processing expectation is "choose exactly one".

As far as the simplicity of the proposed solutions goes, it seems like
the simplest solution for now might be just to add type="choice" on
Substeps. I don't think that'd preclude us from adding a Stepalternives
element later, if the response that emerges from wider user community is
that type="choice" on Substeps isn't meeting their needs.

>   And allow stepalternatives at the top level.

Is it possible that for now that we might be able to separate these two
issues? (That is, the issue of allowing choice markup at the Substep
level, and the issue of allowing choice markup at the top level of
Procedure.)

I hope that before we decide either way on issue on adding choice markup
at the top level, we can discuss the idea of adding a general "Steps" or
"Stepset" wrapper.

I've gone ahead and filed a separate RFE, RFE 640090, proposing that.

  https://sourceforge.net/tracker/index.php?func=detail&aid=640090&group_id=21935&atid=384107

I'm concerned that if we were to first add a specific wrapper for step
alternatives, it might prevent us from considering the idea of adding a
more general wrapper for grouping steps (which would provide users with
the flexibility to group sets of steps in a other ways).

> * Add "topic" markup to cover the more general case of "task" as well
>   as a number of other things.
> 
>   The general "shape" of <topic> would be:
> 
>     optional blockinfo, component.mix stuff, followed by
>     <topicsection> a new (recursive) section element for topic
>     sections.

I agree that we should add a Topic element. I think we also need to
decide what content models to add it to -- what its allowed parent
elements should be. That is, whether it will be allowed, say, wherever
formal objects or now allowed, or wherever sections are now allowed, or
paragraphs, or...

  --Mike