Re: [Scrollkeeper-devel] structure of extracted index page



Hi Mary,

I suspect you know more about indexing with DocBook than almost anybody
else on these lists.  I'll give a shot at an answer, and you can correct
me where I go wrong ;)

My understanding is that id's are optional on all the indexing tags of
interest here: indexterm, see, seealso (and maybe others...)

Do you know what collateindex.pl does with indexterms which do not have
id's?  I tried to make a small test document which generates a nice index
but wasn't successful within just a few minutes.  Do you have a test
document handy we can play with?  I am guessing that it can generate an
index independent of whether the indexterms have id's.

It is certainly convenient if all the indexterms have id's, as it is
easier to link to them from the index.  This is very similar to how the
TOC links to section id's though.  Jade deals with sections without id's
by assigning id's to them.  It can do this because it is generating both
the anchors and the links in the same output.

Suppose we continued to use on-the-fly conversion from SGML to HTML:

The difficulty with ScrollKeeper creating an index off of an SGML
document, or even a TOC off an SGML document, which doesn't have id's is
that the generated index or TOC has to predict the id's (ie. anchors)
which will be assigned to those sections or indexterms by the converter at
run time.  If we know how this assignment will be done, we are ok.  
Otherwise, we must require that all sections and indexterms (and <see> and
<seealso>) have id's.  This is what we are doing now in the GDP, but is
not really a great solution since we are making further restrictions on
top of DocBook.  Thus SK would not work with just any DocBook doc, but a
certain subset of all DocBook docs.  So the better solution is to come up
with a scheme which will assign id's in a predictable way.  This method
would be used by ScrollKeeper during the index creation and during
gnome-db2html2/gnome-db2html3 during display.  The downside to this is
that ScrollKeeper would need to know in advance which display system will
be used.  So long as GNOME and KDE follows the system used by
collateindex.pl, we should not have any problems.

Laszlo - Does this all sound correct based on your experience?  How do you
handle sections without id's in ScrollKeeper's TOC extraction?  Do you
ignore those sections or id them in the same way as db2html?

The other possibility is that instead of trying to refer to an anchor in
the generated HTML, we try to refer to the position in the XML document.  
I really don't know how this would work exactly, since I am not very
familiar with libxml, but it may be possible.  (DV?)

Dan



On Wed, 25 Apr 2001, Mary Dwyer wrote:

> hi
> 
> I'd appreciate some feedback/suggestions on the structure of the index 
> scrollkeeper will create from a document.
> 
> To aid explanation, consider a document including the following index markups:
> 
> <indexterm id="idx-a1">
>   <primary>Apple</primary><secondary>Big </secondary><tertiary>Green</tertiary>
> </indexterm>
> 
> <indexterm zone="a1"><primary>Orange</primary><secondary>Medium></secondary>
> </indexterm>
> 
> <indexterm id="idx-a2" class=startofrange>
>   <primary>Banana</primary><secondary>Small</secondary>
> </indexterm>
> <indexterm startref="idx-a2" class=endofrange>
> 
> 
> 
> 
> The Example below is an excerpt from the extracted index .
>  
> 1. The tags <indexdoc> </indexdoc> indicate beginning and end of document
> 2. The index entry is indicated by the tags <indexentry linkid="id"> 
> </indexentry>
> 
> I do not know how to handle See and See Also references (as they are not 
> associatied with an id) - any suggestions?
> 
> 
> Example:
> 
> <indexdoc>
>    <indexentry linkid="idx-a1">Apple, Big, Green
>    </indexentry>
>    <indexentry linkid="idx-a2">Banana, Small
>    </indexentry>
>    <indexentry linkid="a1">Orange, Medium
>    </indexentry
>       
>    etc. .......
>    
> </indexdoc>   
> 
> 
> 
> TIA
> Mary
> 
> 
> 
> 
> ~ I speak for myself, not for my employer ~
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Mary Dwyer
> Desktop Applications & Middleware Grp
> Sun Microsystems Ireland
> Tel: +353-1-8199222 (xt 19222)
> Fax: +353-1-8199078
> email: mary dwyer ireland sun com
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 
> 
> _______________________________________________
> Scrollkeeper-devel mailing list
> Scrollkeeper-devel lists sourceforge net
> http://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel
> 






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]