This is the mail archive of the
docbook-apps@lists.oasis-open.org
mailing list .
Re: [docbook-apps] Entities references vs. XRef as a way to manage changingglossary
- From: Taro Ikai <tikai at ABINITIO dot COM>
- To: Bob Stayton <bobs at sco dot com>
- Cc: docbook-apps at lists dot oasis-open dot org
- Date: Mon, 4 Aug 2003 15:50:25 -0400
- Subject: Re: [docbook-apps] Entities references vs. XRef as a way to manage changingglossary
> > xsltproc --stringparam collect.xref.targets "only" docbook.xsl
test.xml
> >
> > is like this:
> >
> > <div element="chapter" href="" number="1" targetptr="dessert">
> > <ttl>Dessert</ttl>
> > <xreftext>Chapter??1, <i>Tiramisu</i></xreftext>
> > </div>
>
> I don't understand why the href attribute is blank.
> It should be "#id", where id is either the element's
> id value or a generated id. That was why I thought
> it would be necessary to delete those attribute values
> that are generated.
Sorry, Bob. I had copied the block above after I emptied the value of
@href
attribute according to your suggestion. What
xsltproc --stringparam collect.xref.targets "only" docbook.xsl test.xml
really produces is the following:
<div element="chapter" href="#dessert" number="1" targetptr="dessert">
<ttl>Dessert</ttl>
<xreftext>Chapter??1, <i>Tiramisu</i></xreftext>
</div>
Like you said, it seems necessary to empty the @href attribute value to
turn off production of hotlinks.
> One other option might be XInclude. It will survive
> XSL identity transformations if you don't turn on
> xinclude processing (omit the --xinclude option to
> xsltproc). If you need to import the parameterization
> to FrameMaker, then you could convert the XIncludes
> to entities just before import, and then FrameMaker
> will handle them.
>
XInclude is another technique we can use for parameterizing text I
was not aware of. With XInclude, given glossary.xml:
<glossary>
<varname id="main_course">fish</varname>
<varname id="dessert">apple pie</varname>
</glossary>
I can make a reference to a glossary entry as follows:
<xi:include
href="glossary.xml#xpointer(range-inside(//*[@id='dessert']))"
parse="xml"/>
Compared to the olink technique, where the glossary looks like:
<div targetptr="main_course"><xreftext>beef</xreftext></div>
<div targetptr="dessert"><xreftext>tiramisu</xreftext></div>
and the reference looks like:
<olink targetdoc="glossary" targetptr="dessert"/>
My observations/questions are:
1) XInclude requires each glossary entry to be wrapped in an
element. Here, I've used <varname>, but what if I don't want
any wrapping element? Is there any way to return only the character
data inside?
(Note: I understand this can potentially be a convenience.)
2) The XInclude technique's referencing element is textually more
verbose, and so visually more intrusive. Is there any way to
make the reference more terse?
3) With XInclude, I don't need a special XSLT stylesheet to
resolve the references. XSLT processor does this for us.
4) With XInclude, I don't need to build the target database
as required with olink.
Taro Ikai
---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org