OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]