Menu
▾
▴
scrollkeeper-devel
|
From: Mary D. <Mar...@Su...> - 2001-05-24 15:41:11
|
Laszlo Kovacs wrote: > > > > 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. - yes, it's because there are two indexterm entries in the original document as follows: <indexterm id="idx-a2"><primary>Panel</primary></indexterm> <indexterm id="idx-a9"><primary>Panel</primary></indexterm> granted, in a correctly written help document this shouldn't occur ... > > > > 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. - ok, can name it 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? - it's due to the way I'm generating the ids. In the above example when the stylesheet is outputing the Main Menu, Example entry it generates an id and outputs it (id10791). Then when the <see> entry (Chapter, Example) is being output, need to be able to match the <see> content to the correct indexterm. This is done by means of keys, so need to know how the <see>content is written in order to construct the keys. ...... If this restriction is an issue I can do some more investigation - may be able to solve it using the translate function to eliminate commas, spaces for the key .... Mary > > Laszlo ~ 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: Mary D. <Mar...@Su...> - 2001-05-25 08:14:54
|
Hi
From the stylesheet point of view, if we get the main entry for duplicate i=
ndex=20
terms correct, the see/seealso references will follow.
So, to recap, here's an example of the problem:
- there are multiple sections in the document indexed by the term "Panel". =
These=20
sections have the identifiers idx-a2, idx-a5, idx-a9. There are also a numb=
er of=20
see/seealso references to "Panel"
- under the current stylesheet structure this would result in the index ent=
ry
<primary>
<title linkid=3D"idx-a2" indexid=3D"id10715">Panel</title>
<title linkid=3D"idx-a5" indexid=3D"id10715">Panel</title>
<title linkid=3D"idx-a9" indexid=3D"id10715">Panel</title>
=20
- the following solution appealed, but unfortunately ID and IDREFs as eleme=
nt=20
content is illegal :-)
<primary>
<title>Panel</title>
<linkid>idx-a2</linkid>
<linkid>idx-a5</linkid>
<linkid>idx-a9</linkid>
<indexid>id10715</indexid>
=20
Does anyone have any suggestions on the best way of presenting multiple=20
occurences of an indexterm??
cheers
Mary
> Subject: Re: [Scrollkeeper-devel] extracted index
> From: Gregory Leblanc <gle...@cu...>
> To: scr...@li...
> Mime-Version: 1.0
> X-BeenThere: scr...@li...
> X-Mailman-Version: 2.0.5
> List-Help:=20
<mailto:scr...@li...?subject=3Dhelp>
> List-Post: <mailto:scr...@li...>
> List-Subscribe:=20
<http://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel>,=20
<mailto:scr...@li...?subject=3Dsubscrib=
e>
> List-Id: <scrollkeeper-devel.lists.sourceforge.net>
> List-Unsubscribe:=20
<http://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel>,=20
<mailto:scr...@li...?subject=3Dunsubscr=
ibe>
> List-Archive: <http://lists.sourceforge.net/archives//scrollkeeper-devel/=
>
> Date: 24 May 2001 10:47:11 -0700
>=20
> On 24 May 2001 18:25:06 +0100, L=E1szl=F3 Kov=E1cs wrote:
> > Gregory Leblanc wrote:
> > >=20
> > > On 24 May 2001 16:37:59 +0100, Mary Dwyer wrote:
> > > > Laszlo Kovacs wrote:
> > > > > >
> > > > > > 2. If an indexterm occurs more than once in the original docume=
nt=20
then will
> > > > > > result in a duplicate entry such as this eg.
> > > > > > <primary>
> > > > > > <title linkid=3D"idx-a2" id=3D"id10715">Panel</title>
> > > > > > <title linkid=3D"idx-a9" id=3D"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 the=
re=20
are
> > > > > actually two different Panel descriptions in the text? Because if=
yes
> > > > > then the document is probably incorrectly written.
> > > >
> > > > - yes, it's because there are two indexterm entries in the original=
=20
document as
> > > > follows:
> > > > <indexterm id=3D"idx-a2"><primary>Panel</primary></indexterm>
> > > > <indexterm id=3D"idx-a9"><primary>Panel</primary></indexterm>
> > > >
> > > > granted, in a correctly written help document this shouldn't occur =
...
> > >=20
> > > That's clearly not correct. Open up a book that you have which conta=
ins
> > > an index, and you'll see a very large number of index terms that show=
up
> > > on multiple pages. Usually something like
> > >=20
> > > Cats, Big.... 13, 25, 256
> > >=20
> > > So this is not a error in the document, as far as I'm concerned.
> > > Greg
> >=20
> > Yeah, I was probably to tired. It is correct of course. It raises a
> > couple of issues though.
> >=20
> > 1. I wonder how we implement this in the GUI.
>=20
> Dunno, I'm not a GUI designer. :-)
>=20
> > 2. If we have a See Also: Panel, then to which Panel definition we jump=
.
>=20
> Ah, that one is easy (erm, I think it's easy)! You don't like to an
> entry in the document, you link the the Index entry for the Panel.
> Didn't GNOME recruit some indexing professionals to do some volunteer
> work? Can we sucker^W volunteer them for this discussion?
> Greg
>=20
> --=20
> Troll, troll, troll your post
> Gently down the feed
> Merrily, merrily troll along
> A life is what you need...
>=20
>=20
> _______________________________________________
> Scrollkeeper-devel mailing list
> Scr...@li...
> http://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel
~ I speak for myself, not for my employer ~
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-=3D
Mary Dwyer
Desktop Applications & Middleware Grp
Sun Microsystems Ireland
Tel: +353-1-8199222 (xt 19222)
Fax: +353-1-8199078
email: mar...@ir...
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-=3D
|
|
From: Dan M. <d-...@uc...> - 2001-05-25 17:27:41
|
On Fri, 25 May 2001, Mary Dwyer wrote:
> Hi
>
> >From the stylesheet point of view, if we get the main entry for duplicate index
> terms correct, the see/seealso references will follow.
>
> So, to recap, here's an example of the problem:
> - there are multiple sections in the document indexed by the term "Panel". These
> sections have the identifiers idx-a2, idx-a5, idx-a9. There are also a number of
> see/seealso references to "Panel"
> - under the current stylesheet structure this would result in the index entry
> <primary>
> <title linkid="idx-a2" indexid="id10715">Panel</title>
> <title linkid="idx-a5" indexid="id10715">Panel</title>
> <title linkid="idx-a9" indexid="id10715">Panel</title>
Right. I hadn't thought of this until you pointed it out. This does not
describe what the index really looks like - it has one Panel item with
three links, not three items named "Panel" each with one link. For this
reason, the id's should be children instead of attributes.
> - the following solution appealed, but unfortunately ID and IDREFs as element
> content is illegal :-)
Why is it illegal?
> <primary>
> <title>Panel</title>
> <linkid>idx-a2</linkid>
> <linkid>idx-a5</linkid>
> <linkid>idx-a9</linkid>
> <indexid>id10715</indexid>
>
> Does anyone have any suggestions on the best way of presenting multiple
> occurences of an indexterm??
I think you are headed in exactly the right direction here. Because an
index item may occur in multiple places, it probably makes more sense to
use child elements instead of attributes as we originally discussed.
This makes the file a little longer, but we can always make the titles
attributes if we care about XML bloat.
The long version is:
<indexdoc>
<primary>
<title>Apple</title>
<secondary>
<title>Big</title>
<tertiary>
<title>Green</title>
<linkid>idx-a1</linkid>
<linkid>idx-a2</linkid>
</tertiary>
<tertiary>
<title>Blue</title>
<linkid>idx-a3</linkid>
</tertiary>
<tertiary>
<title>New York City</title>
<seealso>sa-a1</seealso>
</tertiary>
</secondary>
</primary>
<primary>
<title>Banana</title>
<secondary>
<title>Small</title>
<linkid>idx-a2</linkid>
</secondary>
</primary>
<primary>
<title>New York City</title>
<linkid>idx-a5</linkid>
<id>sa-1</id>
</primary>
</indexdoc>
If we shorten it with attributes, it is easier to read and distinguish
which parts are repeatable and which are not:
<indexdoc>
<primary title="Apple">
<secondary title="Big">
<tertiary title="Green">
<linkid>idx-a1</linkid>
<linkid>idx-a2</linkid>
</tertiary>
<tertiary title="Blue">
<linkid>idx-a3</linkid>
</tertiary>
<tertiary title="New York City">
<seealso>sa-a1</seealso>
</tertiary>
</secondary>
</primary>
<primary title="Banana">
<secondary title="Small">
<linkid>idx-a2</linkid>
</secondary>
</primary>
<primary title="New York City" id="sa-1">
<linkid>idx-a5</linkid>
</primary>
</indexdoc>
Dan
|
|
From: Karl E. <ke...@gm...> - 2001-05-25 20:17:37
|
Dan Mueth <d-...@uc...> writes:
> If we shorten it with attributes, it is easier to read and distinguish
> which parts are repeatable and which are not:
Don't do this. As a general rule: Don't hide "running" text inside of
attributes. If you use a proper Editor the element contents are visible
(eg., use a light grey for the element names).
--
work : ke...@su... | ,__o
: http://www.suse.de/~ke/ | _-\_<,
home : ke...@gm... | (*)/'(*)
|
|
From: Dan M. <d-...@uc...> - 2001-05-25 20:48:05
|
On 25 May 2001, Karl Eichwalder wrote: > Dan Mueth <d-...@uc...> writes: > > > If we shorten it with attributes, it is easier to read and distinguish > > which parts are repeatable and which are not: > > Don't do this. As a general rule: Don't hide "running" text inside of > attributes. If you use a proper Editor the element contents are visible > (eg., use a light grey for the element names). I'm curious where the rule against having running text in attributes comes from. Is it technical, conventional, or aesthetic? In the end, I don't think it will matter very much whether we use attributes or children since index files will never be written or edited by hand. I think it does make things a little more clear in at least my email client, which does not put element names in grey ;) Dan |
|
From: Karl E. <ke...@gm...> - 2001-05-26 05:10:16
|
Dan Mueth <d-...@uc...> writes:
> I'm curious where the rule against having running text in attributes
> comes from. Is it technical, conventional, or aesthetic?
All three. But you're sure you will never have to a further markup to
the text exeptions are possible.
> In the end, I don't think it will matter very much whether we use
> attributes or children since index files will never be written or
> edited by hand.
Okay.
> I think it does make things a little more clear in at least my
> email client, which does not put element names in grey ;)
Mine applies nice colors; Gnus treats SGML "tags" like quotation markers
;) From the Gnus manual:
Article Highlighting
--------------------
Not only do you want your article buffer to look like fruit salad,
but you want it to look like technicolor fruit salad.
Nice weekend,
Karl
--
work : ke...@su... | ,__o
: http://www.suse.de/~ke/ | _-\_<,
home : ke...@gm... | (*)/'(*)
|
|
From: <las...@su...> - 2001-05-26 10:07:22
|
Dan Mueth wrote: > > On Fri, 25 May 2001, Mary Dwyer wrote: > > > Hi > > > > >From the stylesheet point of view, if we get the main entry for duplicate index > > terms correct, the see/seealso references will follow. > > > > So, to recap, here's an example of the problem: > > - there are multiple sections in the document indexed by the term "Panel". These > > sections have the identifiers idx-a2, idx-a5, idx-a9. There are also a number of > > see/seealso references to "Panel" > > - under the current stylesheet structure this would result in the index entry > > <primary> > > <title linkid="idx-a2" indexid="id10715">Panel</title> > > <title linkid="idx-a5" indexid="id10715">Panel</title> > > <title linkid="idx-a9" indexid="id10715">Panel</title> > > Right. I hadn't thought of this until you pointed it out. This does not > describe what the index really looks like - it has one Panel item with > three links, not three items named "Panel" each with one link. For this > reason, the id's should be children instead of attributes. > > > - the following solution appealed, but unfortunately ID and IDREFs as element > > content is illegal :-) > > Why is it illegal? I think Norman Walsh said to Mary we shouldnt do it like this. Norm, is this what happened? Laszlo |
|
From: Mary D. <Mar...@Su...> - 2001-05-28 09:29:43
|
< Dan Meuth wrote> > Right. I hadn't thought of this until you pointed it out. This does not > describe what the index really looks like - it has one Panel item with > three links, not three items named "Panel" each with one link. For this > reason, the id's should be children instead of attributes. > > > - the following solution appealed, but unfortunately ID and IDREFs as element > > content is illegal :-) > > Why is it illegal? Norm Walsh pointed out, from the following example, that | <primary> | <title>Main Menu</title> | <secondary> | <title>Example</title> | <linkid>idx-a3</linkid> | <id>id10533</id> ".... putting ID or IDREF values in element content is discouraged by the W3C XML Schemas Recommendation and simply won't work for DTDs." Given what Laszlo pointed out earlier about my incorrect use of <id>, I'm not sure whether the above applies just to a misuse of the <id> tag in my example or whether it also applies to an entry such as <linkid>idx-a3</linkid> ? Mary > > > <primary> > > <title>Panel</title> > > <linkid>idx-a2</linkid> > > <linkid>idx-a5</linkid> > > <linkid>idx-a9</linkid> > > <indexid>id10715</indexid> > > > > Does anyone have any suggestions on the best way of presenting multiple > > occurences of an indexterm?? > > I think you are headed in exactly the right direction here. Because an > index item may occur in multiple places, it probably makes more sense to > use child elements instead of attributes as we originally discussed. > > This makes the file a little longer, but we can always make the titles > attributes if we care about XML bloat. > > The long version is: > > <indexdoc> > <primary> > <title>Apple</title> > <secondary> > <title>Big</title> > <tertiary> > <title>Green</title> > <linkid>idx-a1</linkid> > <linkid>idx-a2</linkid> > </tertiary> > <tertiary> > <title>Blue</title> > <linkid>idx-a3</linkid> > </tertiary> > <tertiary> > <title>New York City</title> > <seealso>sa-a1</seealso> > </tertiary> > </secondary> > </primary> > <primary> > <title>Banana</title> > <secondary> > <title>Small</title> > <linkid>idx-a2</linkid> > </secondary> > </primary> > <primary> > <title>New York City</title> > <linkid>idx-a5</linkid> > <id>sa-1</id> > </primary> > </indexdoc> > > If we shorten it with attributes, it is easier to read and distinguish > which parts are repeatable and which are not: > > <indexdoc> > <primary title="Apple"> > <secondary title="Big"> > <tertiary title="Green"> > <linkid>idx-a1</linkid> > <linkid>idx-a2</linkid> > </tertiary> > <tertiary title="Blue"> > <linkid>idx-a3</linkid> > </tertiary> > <tertiary title="New York City"> > <seealso>sa-a1</seealso> > </tertiary> > </secondary> > </primary> > <primary title="Banana"> > <secondary title="Small"> > <linkid>idx-a2</linkid> > </secondary> > </primary> > <primary title="New York City" id="sa-1"> > <linkid>idx-a5</linkid> > </primary> > </indexdoc> > > Dan > ~ 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... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ------------- End Forwarded Message ------------- ~ 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: Dan M. <d-...@uc...> - 2001-05-29 05:23:36
|
On Mon, 28 May 2001, Mary Dwyer wrote:
> < Dan Meuth wrote>
>
> > Right. I hadn't thought of this until you pointed it out. This does not
> > describe what the index really looks like - it has one Panel item with
> > three links, not three items named "Panel" each with one link. For this
> > reason, the id's should be children instead of attributes.
> >
> > > - the following solution appealed, but unfortunately ID and IDREFs as
> element
> > > content is illegal :-)
> >
> > Why is it illegal?
>
> Norm Walsh pointed out, from the following example, that
> | <primary>
> | <title>Main Menu</title>
> | <secondary>
> | <title>Example</title>
> | <linkid>idx-a3</linkid>
> | <id>id10533</id>
>
> ".... putting ID or IDREF values in element content is discouraged
> by the W3C XML Schemas Recommendation and simply won't work for DTDs."
>
> Given what Laszlo pointed out earlier about my incorrect use of <id>, I'm not
> sure whether the above applies just to a misuse of the <id> tag in my example or
> whether it also applies to an entry such as <linkid>idx-a3</linkid> ?
I'm not certain what the rational behind this recommendation is, or
whether it would apply to our situation. At any rate, I think we can
easily follow the recommendation and make this into an attribute:
<indexdoc>
<primary title="Apple">
<secondary title="Big">
<tertiary title="Green">
<link linkid="idx-a1"/>
<link linkid="idx-a2"/>
</tertiary>
...
instead of the previously suggested:
<indexdoc>
<primary title="Apple">
<secondary title="Big">
<tertiary title="Green">
<linkid>idx-a1</linkid>
<linkid>idx-a2</linkid>
</tertiary>
Dan
|
|
From: Mary D. <Mar...@su...> - 2001-05-28 09:38:24
|
> > 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="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). > > This might be a problem considering the variety of sources documents are > > coming from. Why is this needed? Dan it's more a problem of how to generate the id. ie, when outputing the 'main' term need a way of generating an id which can be generated again when outputing the see/seealso term. The only way I have figured to match a see/seealso value to the appropriate index entry is via a key. But in order to construct the "use" element of the key I need to know how the see/seealso value is constructed (ie spaces, commas between terms etc). This will be clearer when I commit the stylesheet to SK CVS - in the meantime if anyone has any ideas/suggestions ..... cheers mary > > 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="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="id10791" ptitle="Main Menu" stitle="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="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 > ~ 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: Mary D. <Mar...@Su...> - 2001-05-29 08:14:51
|
hi sounds good to me -I'll implement it thanks Mary <Dan Meuth wrote> > > I'm not certain what the rational behind this recommendation is, or > whether it would apply to our situation. At any rate, I think we can > easily follow the recommendation and make this into an attribute: > > <indexdoc> > <primary title="Apple"> > <secondary title="Big"> > <tertiary title="Green"> > <link linkid="idx-a1"/> > <link linkid="idx-a2"/> > </tertiary> > ... > > instead of the previously suggested: > > <indexdoc> > <primary title="Apple"> > <secondary title="Big"> > <tertiary title="Green"> > <linkid>idx-a1</linkid> > <linkid>idx-a2</linkid> > </tertiary> > > Dan > > > ~ 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... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ------------- End Forwarded Message ------------- ~ 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: Gregory L. <gle...@cu...> - 2001-05-24 17:20:36
|
On 24 May 2001 16:37:59 +0100, Mary Dwyer wrote:
> Laszlo Kovacs wrote:
> > >
> > > 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.
>
> - yes, it's because there are two indexterm entries in the original document as
> follows:
> <indexterm id="idx-a2"><primary>Panel</primary></indexterm>
> <indexterm id="idx-a9"><primary>Panel</primary></indexterm>
>
> granted, in a correctly written help document this shouldn't occur ...
That's clearly not correct. Open up a book that you have which contains
an index, and you'll see a very large number of index terms that show up
on multiple pages. Usually something like
Cats, Big.... 13, 25, 256
So this is not a error in the document, as far as I'm concerned.
Greg
--
Troll, troll, troll your post
Gently down the feed
Merrily, merrily troll along
A life is what you need...
|
|
From: <las...@su...> - 2001-05-24 17:31:18
|
Gregory Leblanc wrote: > > On 24 May 2001 16:37:59 +0100, Mary Dwyer wrote: > > Laszlo Kovacs wrote: > > > > > > > > 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. > > > > - yes, it's because there are two indexterm entries in the original document as > > follows: > > <indexterm id="idx-a2"><primary>Panel</primary></indexterm> > > <indexterm id="idx-a9"><primary>Panel</primary></indexterm> > > > > granted, in a correctly written help document this shouldn't occur ... > > That's clearly not correct. Open up a book that you have which contains > an index, and you'll see a very large number of index terms that show up > on multiple pages. Usually something like > > Cats, Big.... 13, 25, 256 > > So this is not a error in the document, as far as I'm concerned. > Greg Yeah, I was probably to tired. It is correct of course. It raises a couple of issues though. 1. I wonder how we implement this in the GUI. 2. If we have a See Also: Panel, then to which Panel definition we jump. Laszlo |
|
From: Gregory L. <gle...@cu...> - 2001-05-24 17:47:06
|
On 24 May 2001 18:25:06 +0100, László Kovács wrote:
> Gregory Leblanc wrote:
> >
> > On 24 May 2001 16:37:59 +0100, Mary Dwyer wrote:
> > > Laszlo Kovacs wrote:
> > > > >
> > > > > 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.
> > >
> > > - yes, it's because there are two indexterm entries in the original document as
> > > follows:
> > > <indexterm id="idx-a2"><primary>Panel</primary></indexterm>
> > > <indexterm id="idx-a9"><primary>Panel</primary></indexterm>
> > >
> > > granted, in a correctly written help document this shouldn't occur ...
> >
> > That's clearly not correct. Open up a book that you have which contains
> > an index, and you'll see a very large number of index terms that show up
> > on multiple pages. Usually something like
> >
> > Cats, Big.... 13, 25, 256
> >
> > So this is not a error in the document, as far as I'm concerned.
> > Greg
>
> Yeah, I was probably to tired. It is correct of course. It raises a
> couple of issues though.
>
> 1. I wonder how we implement this in the GUI.
Dunno, I'm not a GUI designer. :-)
> 2. If we have a See Also: Panel, then to which Panel definition we jump.
Ah, that one is easy (erm, I think it's easy)! You don't like to an
entry in the document, you link the the Index entry for the Panel.
Didn't GNOME recruit some indexing professionals to do some volunteer
work? Can we sucker^W volunteer them for this discussion?
Greg
--
Troll, troll, troll your post
Gently down the feed
Merrily, merrily troll along
A life is what you need...
|
|
From: <las...@su...> - 2001-05-24 18:10:31
|
> > 2. If we have a See Also: Panel, then to which Panel definition we jump. > > Ah, that one is easy (erm, I think it's easy)! You don't like to an > entry in the document, you link the the Index entry for the Panel. > Didn't GNOME recruit some indexing professionals to do some volunteer > work? Can we sucker^W volunteer them for this discussion? Ah, I was thinking more from a GUI, usability point of view. laszlo |