Re: [docbook] links within classsynopsis?

[Michael Smith <smith@xml-doc.org>]

Stephen Langer <stephen.langer@nist.gov> writes:

> I've found another problem with <methodsynopsis>.   How would I mark  
> up a C++ const function prototype?
> I want something like this:
>    virtual int function() const;
> But I can only obtain this:
>    virtual const int function();
> which isn't the same thing.  The xsl stylesheet doesn't differentiate  
> between <modifier>s applied before and after <methodname>.
> 
> This is what I tried doing:
> 
>     <classsynopsis>
>       <ooclass>
>       <classname>Test</classname>
>       </ooclass>
>       <methodsynopsis>
>       <modifier>virtual</modifier>
>       <type>int</type>
>       <methodname>function</methodname>
>       <modifier>const</modifier>
>       <void/>
>       </methodsynopsis>
>     </classsynopsis>

OK, having a Modifier after the Methodname is valid in both
DocBook 4 and DocBook 5. So the above is basically OK. But that
final Void is not valid where you have it. And for DocBook 5, you
also need to have a Methodparam or Void after the Methodname.

The problem with processing the above is that the stylesheets do
not render the contents of Methodsynpsis in document order. They
render it in order of "all modifiers grouped together", followed
by "everything else that is not a modifier".

Specifically, the stylesheets currenly do matches to create the
following variables:

  <xsl:variable name="modifiers" select="modifier"/>
  <xsl:variable name="notmod" select="*[name(.) != 'modifier']"/>

And then they apply templates to the contents of those variables,
first to the $modifiers content, then to the $notmod content.

That logic seems to not consider the case where a Methodsynopsis
has a Modifier at the end. Perhaps it is a intentional design
decision. But it seems like an oversight. Can you please file a
bug report for it -

  https://sourceforge.net/tracker/?func=add&group_id=21935&atid=373747

You will need to have a Sourceforge account to file it. If it's
too much of a hassle, let me know, and I will file it myself.

I think we probably need to refine the select matches for those
variables to:

  <xsl:variable name="start-modifiers"
    select="modifier[following-sibling::*[name(.) != 'modifier']]"/>
  <xsl:variable name="notmod" select="*[name(.) != 'modifier']"/>
  <xsl:variable name="end-modifiers"
    select="modifier[preceding-sibling::*[name(.) != 'modifier']]"/>

And then process it in order start-notmods-endmods

  --Mike
-- 
Michael Smith
http://sideshowbarker.net/

smime.p7s