[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook-apps] Collecting glossentries in glossary database
David Cramer (Tech Pubs) wrote: >The downsides of using linkends and ids are: > >1) You must include the glossary in the doc so that it will validate (or >modify the DTD so it won't consider linkends on glossterms IDREFs). > > Yes, you are right. But maybe a (pre)process similar to target-db generation for olinking could solve this. >2) It's extra work for the writer to add the linkend to every glossterm, >and > > Debugging the document because you misspelled the glossterm is also extra work ;-) >3) If you're editor helps you out by populating other IDREF attributes >with all the IDs in the doc, all the glossentry ids will clutter that >list of candidate IDs (which would otherwise consist mostly of chapter >and sections). > > I have >500 Ids in my documentation of a software module (1 out of 7). If one uses prefixes consequently for every sort of id, finding the right id isn't that difficult anymore. But a lot of discipline is needed if you work in multi-author environment. My editor sorts the id's and is able to filter the prefix "glo-" when I'm using linkend in the context of glossterm. >We do use linkends and ids and some glossary generation xslts of our own >that predate the ones in the stock xsls. We have a system that actually >modifies the DTD so that the linkend attribute on glossterm is an >enumeration of all the ids in our master glossary (i.e. that bit of the >dtd is dynamically generated). That solves #1 and #2. #3 we solve by >customizing the editor. It all ends up working, but took effort to set >up. > > Modifying the DTD isn't very straight forward and doesn't solve the problem of the ambiguity with acronyms described in my 2nd mail :-(. Perhaps I'll try to figure out a small stylesheet for collecting the effectively used glossterms. A copy process on the glossary database, that kicks out all glossentries, that weren't referenced - shouldn't be that difficult. BTW, a small script, that sorts the glossentries in a glossary (respecting glossdiv,...), would be welcome as well, or I have to write it myself. Georges >David > > > >>-----Original Message----- >>From: Georges Schmitz [mailto:georges.schmitz@heitec.de] >>Sent: Thursday, July 07, 2005 9:14 AM >>To: docbook-apps >>Subject: Re: [docbook-apps] Collecting glossentries in >>glossary database >> >>Using text content of glossterms, one drawback comes into my >>mind: the existing mechansim cannot deal with 2 acronyms >>spelled in the same way, but meaning different things. This >>may exactly happen in the aviation licensing domain; you have >>international and national acronyms that intersect. >> >>If I split national and international glossterms in different >>glossdivs, I cannot even be sure, that linking gets me to the >>right page. >> >>Just a thought... >>Georges >> >> >> >>>...<glossterm linkend="glo-jar">JAR</glossterm>... >>>I'm asking myself why the stylesheets are only relying on the text >>>node content of glossterm and firstterm (or the |baseform| >>> >>> >>attribute), >> >> >>>and why the stylesheet will not collect the glossary >>> >>> >>entries by using >> >> >>>the linkend attribute (wouldn't this be safer anyway)? Is there a >>>special reason for this? >>> >>> >>> > >--------------------------------------------------------------------- >To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org >For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org > > > > > -- -------------------------------------- Georges Schmitz Projektleitung ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Tel: 09131 / 877-176 Fax: 09131 / 877-136 Mob: 0163 / 877 1623 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ HEITEC AG Werner-von-Siemens-Str. 61 91052 Erlangen --------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]