This is the mail archive of the
docbook@lists.oasis-open.org
mailing list for the DocBook project.
Re: [docbook-tc] alternatives
- From: Sabine Ocker - Sun Microsystems <Sabine dot Ocker at Sun dot COM>
- To: pgrosso at arbortext dot com
- Cc: docbook at lists dot oasis-open dot org
- Date: Wed, 18 Sep 2002 14:50:35 -0400 (EDT)
- Subject: DOCBOOK: Re: [docbook-tc] alternatives
- Reply-to: Sabine Ocker - Sun Microsystems <Sabine dot Ocker at Sun dot COM>
>| 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?").
paul
Paul-
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,
Sabine-