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

[Mary D. <Mar...@Su...>]

Hi Dan

yes, it appears ids are optional for indexterms (and not used for "see" and "see 
also").
From what I understand the convertor at run time generates ids where required 
(using generate-id() ).  However, as you point out, I don't believe scrollkeeper 
can predict what these ids will be because:
1) scrollkeeper may use a different convertor to the 'run-time' convertor.
2) even if the same convertor is used the w3.org description indicates that 
  "An implementation is under no obligation to generate the
   same identifiers each time a document is transformed."
   see http://www.w3.org/TR/xslt#function-generate-id

Am I correct in these assumptions?


Your point about generating ids for use within the index doc (for "see" and "see 
also") makes sense and I will incorporate this


cheers
Mary


> 
> 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: mar...@ir...
> > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > 
> > 
> > _______________________________________________
> > Scrollkeeper-devel mailing list
> > Scr...@li...
> > http://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel
> > 
> 
> 

~ 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: mar...@ir...
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=