OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-tc message

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

Subject: Re: DocBook V4.0beta1


Your example in the PostScript below definitely expresses the semantics
better.  I'm just trying to nudge 4.0 to be a little less painful for our

 > / Michael Sabrio <rms@fpk.hp.com> was heard to say:
 > | We have a lot of material that uses Command inline like this:
 > | 
 > |     <Command>cat <Optional><Option>-v</Option></Optional>
 > |                  <Optional><Replaceable>file</Replaceable></Optional>
 > |     </Command>
 > Yipes! We've got to allow that!

Here are a couple of other cases that spring to mind.  The following
markup seems excessive to me; I'm not sure it's canonical, but it still
seems pretty natural, so it seems weird that it's invalid:

   Here's a command that's not a synopsis:

           <command>cat <filename>/etc/passwd</filename></command>

   Cleartext: EBTRC=$HOME/.ebtrc mkbook blah.sgm
      mkbook  <filename>blah.sgm</>

I guess I always thought of command as the "whole command" instead of
just the command name.

 > | Is there any way we could remove Command and Literal from the list of
 > | elements to be restricted to %smallcptr.char.mix in 4.0?
 > That's one option, and it might be the best thing, but is there
 > anything you really want other than Option and Optional? I mean,
 > would (%smallcptr.char.mix;|option|optional)* work for you? (I
 > have reservations about option and optional in literal, but
 > since you've got significant legacy, I won't argue the point :-)

I looked through the inlines, especially tech.char.class, and as
my examples suggest, the ones that seemed most natural in Commands
(and Literals) are Option|Optional|Filename|EnVar; but that seems
a little arbitrary.

I started doing the same exercise for the Function element, but it
uses cptr.char.mix, so my legacy problems never arise.  Can someone
remind me of why we changed Command the way we did, but not Function.

 >                                         Cheers,
 >                                           norm
 > P.S. Wouldn't
 > <cmdsynop><command>cat</command><arg>-v</arg>
 > <arg choice="req"><replaceable>file</replaceable></arg></cmdsynop>
 > express the semantics better? (I'm looking at <optional><option> and
 > my first reaction is "eewww" :-)

That's my reaction, too, except that this use of the term "option" seems
so natural in Unix-speak.  Unfortunately, this vernacular use of "option"
means that "required option" makes sense . . .  My reaction is like yours,
except that I use the pronunciation of my 6-year-old niece -- "eewwwuh" --
thereby making two syllables out of what you swore could be only one.

Thanks and Happy Holidays.


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

Powered by eList eXpress LLC