This is the mail archive of the docbook-apps@lists.oasis-open.org mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [docbook-apps] Entities references vs. XRef as a way to manage changing glossary


On Wed, Aug 06, 2003 at 11:36:22PM -0400, Taro Ikai wrote:
> After investigating the various options for parameterizing text in 
> DocBook, I started thinking about how to map FrameMaker variables
> to this mechanism so I can import/export FM variables and references
> to the glossary entries and references in XML.
> 
> I am now coming to realize that I don't want one-to-one, automated
> translation of FM variables to entities or elements in XML.
> 
> The reason is that FM variables are not guaranteed to be unique across 
> multiple FM files. Different FM files, by default, assign different values
> to identically named variables (i.e. fmv1, fmv2, graphic1, graphic2, 
> etc.).
> This is also applicable to user defined variables where nothing enforces
> uniqueness of names across documents.
> 
> In DocBook, I can define one central glossary document, where the 
> ID/IDREF mechanism ensures that I define a unique name for each 
> glossary entry. With this realization, I'm happy to take on the task of 
> merging and assigning unique names to all glossary entries manually.
> 
> I am hoping that using <glossterm linkend=''/> to parameterize
> text will allow me to map glossary entries between FrameMaker 
> and DocBook, after the one-time conversion I perform.
> 
> The <glossterm id=''/> and <glossterm linkend=''/> elements are not too 
> unlike any element that takes an id attribute and a <xref linkend=''/> 
> element that references it, except <glossterm> does not produce a
> hot linke like <xref> does. I am hopeful that I cab map this element to 
> some FM counterpart, so I can roundtrip documents between DocBook 
> and FrameMaker.

I'm not sure I understand.  An inline glossterm with
@linkend *will* form a hot link.  You can turn off
the hot link by setting the stylesheet parameter
firstterm.only.link to nonzero.  Then only <firstterm>
elements with @linkend will be hot links.

But more importantly, an empty inline glossterm
will not generate text.  The output will be
empty when processed with the XSL stylesheets.
Does that matter?  Are you going to customize
the behavior of the inline glossterm template to work
like an inactive xref?
> 
> <glossterm> also survives XSLT transformation because it's an element.
> FrameMaker by default translates variables to entities and entity 
> references in XML markup, which do not survive XSLT transformation.


Bob Stayton                                 400 Encinal Street
Publications Architect                      Santa Cruz, CA  95060
Technical Publications                      voice: (831) 427-7796
The SCO Group                               fax:   (831) 429-1887
                                            email: bobs@sco.com

---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]