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: How are RFEs handled?


Norm,

What you suggest would work. My only concern is that the API we are documenting is in C or C++ so function is apropos versus Java where method is. I am an electrical engineer who does technical writing for the project (and for my girlfriend's compnay) and has taught myself programming so my strengths are not in programming jargon. I defer to those who do understand the jargon better than I.

As I see it I need a C and C++ element that can handle the access specifier (which could be rolled into the funcdef element) and the function keyword, without generating an error. As long as there is something that can do that, and do it obviously, I will be happy.

Sincerely, Jeff Biss

Norman Walsh wrote:
87hec2iusg.fsf@nwalsh.com">
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

/ Jeff Biss <jeff@marco-inc.com> was heard to say:
| I have submitted an RFE (655526: funcprototype enhancement) in
| SourceForge but see no action, either pro or con on it. I am working
| with the DocBook on an open source project's documentation effort and
| need some enhancement to the existing DocBook to account for function
| prototypes used in the OpenBeOS API.
|
| How are RFEs handled? Is there something I need to do? I am far from
| an XML expert but tried to be as thorough as I could.

Mike's summary describes the process. We get to them as fast as we can.

| I know everyone is busy and don't want to sound pushy but I would like
| to tell my team what to expect of the process. There is no way to
| handle my current situation, as I see it, at this time.

I just added the fol lowing suggestion to your RFE.

Would the following change also satisfy your needs?

funcprototype ::=
(modifier*, funcdef,
(void|varargs|paramdef+),
modifier*)

That would be consistent with the methodsynopsis element. I suppose we
could even make it

funcprototype ::=
(modifier*, funcdef,
(void|varargs|paramdef+),
exceptionname*, modifier*)

Though perhaps that begins to beg the question as to whether
funcprototype is even necessary anymore. Perhaps it should be removed
alltogether in favor of methodsynopsis.

Does that suit your needs? (Do BeOS API functions through exceptions?
Are they properly methods on BeOS objects, or are they really just
part of a function library, not that the distinction is necessarily
deep or clear.)

Be seeing you,
norm

- --
Norman Walsh <ndw@nwalsh.com> | The trip doesn't exist that can
http://www.oasis-open.org/docbook/ | set you beyond the reach of
Chair, DocBook Technical Committee | cravings, fits of temper, or
| fears. If it did, the human race
| would be off there in a
| body.--Seneca
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE+LTSfOyltUcwYWjsRAmKvAKCSNiRXmSanDQcqJ6gAYrN1jZzBigCfTnSd
MKwXIRq9G0scXWZB0/1MTZw=
=RpDZ
-----END PGP SIGNATURE-----






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


Powered by eList eXpress LLC