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: DOCBOOK: Re: [docbook-tc] alternatives

	>|     609061 Add new Step sibling element Alternative
	>NW: Maybe a couple of straw polls will help us settle the issues.
	>Poll 1: The proposal as written attempts to prevent alternatives from occurring
	>recursively (that is, a step with alternatives occurring as a descendent of some
	>other alternative step). Are you in favor of allowing or excluding alternatives:
	>  Allow: 4, Exclude: 2, Abstain: 3
	I would go so far as to say that, if we exclude alternatives
	within alternatives, I would vote against this entire proposal.  
	I see no reason to add all this new stuff if we are going to make 
	it so useless, and not allowing alternatives within steps within 
	alternatives makes the proposal useless in my opinion to say 
	nothing of more confusing for users ("why can't I have an alternative
	here when I can have it there?").

Yes, I can see your point about the usefulness of having nested Alternatives.
At Sun, it's been a part of our overall Docbook DTD subsetting efforts to attempt
to limit recursion to only what's actually needed. In this case, both writer 
advocates and some tools engineers feel that nested Alternatives are not
part of our current requirements. I understand that others might not 
have need for such restrictions. I would like to see this RFE pass and as our 
straw poll yesterday seemed to indicate your opinion was in the majority,
we could, if need be, work around the exclusion.

Thanks for your input,

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

Powered by eList eXpress LLC