DOCBOOK: Re: New element for Step alternatives?

[Sabine Ocker - Sun Microsystems <Sabine.Ocker@sun.com>]

Norm-
See my comments below. Not sure if they could be considered "new information"
but...
	
	I'm trying to recap where we stand on this proposal.
	
	There seems to be general agreement that it's a good idea.
	
(^: This makes me happy...
	
        The question is, exactly what should the markup look like?
	
	My favorite combination of proposals so far is:
	
	1. Procedure remains unchanged
	
	   If you need alternatives at the top level, don't you really have
	   different procedures?
	   
Norm, can you please clarify what you mean by this? Are you saying that you 
think having "choice" ie StepAlternative as a sibling to Step should be 
marked up as two Procedures?   
	
	2. 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".
	
	   While it's true that an attribute on 'substeps' could be used, that
	   seems like too significant a processing expectation to stick in an    
           attribute.
	   (By that rationale, we could have a <list> element with an attribute
	   to choose between ordered and itemized, but we don't.)
	
	   It's also true that stepalternatives could contain (branch+), but     
           that
	   seems unnecessary. Context seems sufficient.
	   
Yes, I agree with this. A Branch and a Step are in essense the same.
	
	If anyone has new information, please send it along soon. I expect
	we'll consider this proposal next Tuesday.
	
Thank you,
Sabine