This is the mail archive of the docbook@lists.oasis-open.org mailing list for the DocBook project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New element for Step alternatives?


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

/ Bob Stayton <bobs@caldera.com> was heard to say:
| But I disagree with Norm's suggestion to also permit
| stepalternatives as a direct child of procedure.
| I think that muddies up the logic of a procedure.

If you don't allow stepalternatives at the top level, you've made the
first step in a procedure different from all the other steps. I don't
see any compelling reason to do that.

| That makes stepalternatives act as a step, which would
| require the component.mix text glue that step has
| for it to work.  It's much cleaner to make it a
| part of a step element's content. 

I don't see how that's the case. If procedure is:

<!ELEMENT procedure (..stuff.., (step+|stepalternatives))>

then you can say either:

<procedure>
  <para>some interesting preamble</para>
  <stepalternatives>
    <step><para>do this</para></step>
    <step><para>or do this</para></step>
  </stepalternatives>
</procedure>

or

<procedure>
  <para>some interesting preamble</para>
  <step><para>do this</para></step>
  <step><para>then do this</para></step>
</procedure>

In either case, you can have additional complexity farther down.

I think I have just convinced myself that the content models should be

  step+|stepalternatives

though and not

  step+|stepalternatives+

| Then a procedure would read like: "first you do this step,
| then you do that step, and in the third step you have to
| make a choice and here are the three choices.
| Then you continue with the fourth step, etc."
|
| Those three choices are not peers of the first two steps,
| they are inside the third step.

Oh, I see now what you mean. Yes, I think you're right. If you want to
have a set of alternatives, you should have to put that in a wrapper
so you can explain the change (and so it'll make sense to use
different presentation for those alternative steps).

| Boiling all this verbiage down, I'm suggesting that the
| only changes we make now are to:
|
| 1.  Add a stepalternatives element whose content model
|     is just (step+)
|
| 2.  Replace (substeps) in the step content model with
|     (substeps|stepalternatives)
|
| These changes would accomodate Sabine's cases, keep the
| content models easy to understand, and leave us room to
| grow--outward rather than inward.

That looks good to me, though I think I still favor having

  step+|stepalternatives

at the top level, for logical consistency.

                                        Be seeing you,
                                          norm

- -- 
Norman Walsh <ndw@nwalsh.com>      | The finest amusements are the most
http://www.oasis-open.org/docbook/ | pointless ones.--Jacques Chardonne
Chair, DocBook Technical Committee |
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE98RnEOyltUcwYWjsRAr0HAJ9OAG56YuEhqYg8dISmQXgMmXdoqACgjMts
sKD1tYJ/QnJMo604xJXLsmI=
=PY4H
-----END PGP SIGNATURE-----


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]