> >> <type>integer</type> <parameter role="ref" > >> choice="opt">width</parameter> > >> > >> VS > >> > >> <parameter role="ref" choice"opt" type="integer">width</parameter> > > > > Parameter has no type attribute, so only the former is possible. > > Ups, parameter also has no choice attribute, it is of paramdef. Which in > turn can only be added inside a funcprototype according to the DocBook > DTD. Couldn't we come up with some DocBook friendly alternative? A good > idea would be to somehow reference the parameter already defined in the > funcprototype, so only one place needs editing when parameters get > changed. Then livedocs could resolve the reference and copy the > parameter info (type, by reference, name) to the right place in the > variablelist.
We may need a livedocs person to tackle this as the structure is already in place. Using the same example we have the following in the methodsynopsis (split from one line to fit in this email): <methodparam choice="opt"> <type>int</type><parameter role="reference">width</parameter> </methodparam> And in the parameter list refsect1 we have a few unique items, first: &reftitle.parameters; And the parameter varlistentries each have this format: <term><parameter>width</parameter></term> So DSSSL would currently parse this as normal whereas livedocs might be able to add the extra information. Whether the existence of the parameters reftitle entity inside the refsect1 is enough for livedocs I don't know but I assume we wouldn't need to use ID's here. On a related note, I assume we'll now use role="reference" within the methodparam's parameter tag instead of & Regards, Philip
