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

[Taro Ikai <tikai at ABINITIO dot COM>]

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.

<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.

Taro