Menu
▾
▴
scrollkeeper-devel
|
From: Mary D. <Mar...@Su...> - 2001-05-24 13:27:00
|
hi
attached is an example of an index extracted using the stylesheet I've written
for scrollkeeper. I'd appreciate if you could have a look at it and provide
some feedback.
A few issues to note:
1. only dealing with indexterms from the original document that include an "id"
or "zone" attribute (in order to provide anchors back to the original document)
2. If an indexterm occurs more than once in the original document then will
result in a duplicate entry such as this eg.
<primary>
<title linkid="idx-a2" id="id10715">Panel</title>
<title linkid="idx-a9" id="id10715">Panel</title>
- this is not ideal, but not sure how to get round this.
3. ids are generated within the index to provide internal links for see and
seealso references. For example, where "Main Menu, Example" is an index
entry, and there is a see reference from "Chapter, Example" to "Main Menu,
Example" the output will be as follows:
<primary>
<title>Chapter</title>
<secondary>
<title>Example</title>
<see id="id10791">Main Menu, Example</see>
</secondary>
</primary>
<primary>
<title>Main Menu</title>
<secondary>
<title linkid="idx-a3" id="id10791">Example</title>
</secondary>
</primary>
In order to be able to match the <see>/<seealso> content to the correct index
term I need to be able to assume the <see>/<seealso> content will be structured
in a set way, ie primary, secondary, tertiary (each term seperated by a comma
and a space - or whatever, once it is consistent).
cheers
Mary
p.s originally sent this mail to the alias with a too large attachment ....
~ 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...
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|
|
From: <las...@Su...> - 2001-05-24 15:08:46
|
Mary Dwyer wrote: > > hi > > attached is an example of an index extracted using the stylesheet I've written > for scrollkeeper. I'd appreciate if you could have a look at it and provide > some feedback. > > A few issues to note: > 1. only dealing with indexterms from the original document that include an "id" > or "zone" attribute (in order to provide anchors back to the original document) > > 2. If an indexterm occurs more than once in the original document then will > result in a duplicate entry such as this eg. > <primary> > <title linkid="idx-a2" id="id10715">Panel</title> > <title linkid="idx-a9" id="id10715">Panel</title> > > - this is not ideal, but not sure how to get round this. We probably need to find some solution for this. Is this like there are actually two different Panel descriptions in the text? Because if yes then the document is probably incorrectly written. > 3. ids are generated within the index to provide internal links for see and > seealso references. For example, where "Main Menu, Example" is an index > entry, and there is a see reference from "Chapter, Example" to "Main Menu, > Example" the output will be as follows: > > <primary> > <title>Chapter</title> > <secondary> > <title>Example</title> > <see id="id10791">Main Menu, Example</see> > </secondary> > </primary> > <primary> > <title>Main Menu</title> > <secondary> > <title linkid="idx-a3" id="id10791">Example</title> > </secondary> > </primary> Isnt there a restriction that id attributes have to be unique throughout the document? If it is then we will need to name the "id" attribute something else. > In order to be able to match the <see>/<seealso> content to the correct index > term I need to be able to assume the <see>/<seealso> content will be structured > in a set way, ie primary, secondary, tertiary (each term seperated by a comma > and a space - or whatever, once it is consistent). This might be a problem considering the variety of sources documents are coming from. Why is this needed? Laszlo |
|
From: Dan M. <d-...@uc...> - 2001-05-25 17:42:49
|
On Thu, 24 May 2001, L=E1szl=F3 Kov=E1cs wrote:
> Mary Dwyer wrote:
>
> > 3. ids are generated within the index to provide internal links for =
see and
> > seealso references. For example, where "Main Menu, Example" is an=
index
> > entry, and there is a see reference from "Chapter, Example" to "Main =
Menu,
> > Example" the output will be as follows:
> >
> > <primary>
> > <title>Chapter</title>
> > <secondary>
> > <title>Example</title>
> > <see id=3D"id10791">Main Menu, Example</see>
> > </secondary>
> > </primary>
> > <primary>
> > <title>Main Menu</title>
> > <secondary>
> > <title linkid=3D"idx-a3" id=3D"id10791">Example</title>
> > </secondary>
> > </primary>
>
> Isnt there a restriction that id attributes have to be unique throughou=
t
> the document? If it is then we will need to name the "id" attribute
> something else.
It looks like the <see> tag above does not want an 'id' attribute, but
instead it needs something like a 'linkid' - perhaps called 'seeid':
<see seeid=3D"id10791">Main Menu, Example</see>
> > In order to be able to match the <see>/<seealso> content to the corr=
ect index
> > term I need to be able to assume the <see>/<seealso> content will be =
structured
> > in a set way, ie primary, secondary, tertiary (each term seperated by=
a comma
> > and a space - or whatever, once it is consistent).
> This might be a problem considering the variety of sources documents ar=
e
> coming from. Why is this needed?
I think we have three options here:
(1) Use the title as one expects all browsers to display them, such as
Mary did: "Main Menu, Example"
<secondary>
<title>Example</title>
<see id=3D"id10791">Main Menu, Example</see>
</secondary>
(2) Provide the information about where it is linking to as metadata so
that the help browser can construct the string however it wants to:
<secondary>
<title>Example</title>
<see id=3D"id10791" ptitle=3D"Main Menu" stitle=3D"Example"/>
</secondary>
(3) Don't bother giving the title of the section you are linking to,
because the help browser can always go in and extract it since it has the
id:
<secondary>
<title>Example</title>
<see id=3D"id10791">
</secondary>
I tend to prefer #2 I think, since it gives the help browser the
flexibility to present the information in different ways without doing
much work.
Dan
|
|
From: Dan M. <d-...@uc...> - 2001-05-25 18:07:07
|
On Thu, 24 May 2001, Mary Dwyer wrote: > A few issues to note: > 1. only dealing with indexterms from the original document that include an "id" > or "zone" attribute (in order to provide anchors back to the original document) There are two general approaches to how we solve this problem which come to my mind: The first is using XPointers. I don't understand how one proceeds from having an XPointer to the right location to actually having XSLT produce the HTML output of the right page and anchor it to the right location. If we can do this without much trouble, then this may be a good solution. Does anybody understand how this works once we have the XPointer? The other is to create a black box id generator which you feed your docs through. For the sake of discussion, I will call it "sk_idattgen" and it will ship as part of ScrollKeeper. It is an executable that you input your SGML or XML doc and it outputs the same docs but it inserts id's anywhere they are missing in a deterministic and reproducable way. It would be simple to do - it could just number all the id's and check to make sure none of the numbers collide with pre-existing id's, for example. ScrollKeeper would run sk_idattgen on any SGML or XML docs it works with before it does any other processing. Any help browser which wants to work properly with ScrollKeeper will have to run sk_idattgen on any doc it works with before it does other processing. (Note this solves the problem not only for indexing, but also for the TOC and potentially other problems that will surely pop up in the future.) I like the later solution because it is so simple to implement and to use, and should be very robust. The main downside to it is the time penalty of having to parse the file an extra time. I don't think it should be noticable on the help browser side. For ScrollKeeper itself, if we really care about performance we can just create a function which does the sk_idattgen work which we call inside the other SK functions so we don't parse the document twice. This will help in cases where we are processing dozens of files and care about performance. Dan |