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-tc] DocBook Technical Committee Meeting Minutes: 17 Sep2002


Norman Walsh <ndw@nwalsh.com> writes:

> |    The following RFEs have been moved to the bottom of this agenda in order
> |    to make sure that all RFEs get fairly discussed.
> | 
> |     514435 Allow reference within refentry
>  
>       Mike: can you summarize where this issue stands?

I *think* the status on this is that we might be able to resolve it by
allowing refpurpose and/or refclass as children of refsect* elements.

The last action item I had related to this was to ask the submittor if
the main thing he would gain from using this markup model (instead of
just using nested sections and methodsynopsis elements) is an ability to
associate a Refpurpose with each of his class members, and whether he
could describe any other advantages.

He wrote back to say,

  Adding a refpurpose and refclass is the main benefit.  In applications
  that generate quickref-style reference ToCs, this is significant.

He provides an example in a dialog he added to the RFE:

  https://sourceforge.net/tracker/index.php?func=detail&aid=514435&group_id=21935&atid=384107

So, I think the consensus when we discussed it was, if the goal is to be
able to associate a Refpurpose with individual class members, there is a
simpler way to implement that than creating nested refentrys and adding a
new floating "reflist" element as he suggested.

I guess that simpler might be to just allow refpurpose and/or refclass
as children of refsect* elements.

  --Mike




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


Powered by eList eXpress LLC