Thomas Schraitle wrote:
Hi,
Thomas Schraitle wrote:
Is the method with @xml:id and linkend not an option for you?
Yes, I think that was my early concern when I realised there
are so many options to choose from! If I'm going to use
the id value, then <xref linkend='idval'/> seems the most
common one? I'm not sure why glossary targets are so special.
Not glossary target, xrefs to glossentrys.
Sorry, I was inexact.
They are "special" as
xref needs a title to resolve it correctly.
A glossentry doesn't have a title. It could be discussed, if this
is an error and should be corrected. Maybe a xref to a glossentry
should use the glossterm.
Works for me Tom?
src: <para>Use a <xref linkend="rule.gloss"/> to trigger an action.
<glossentry >
<glossterm xml:id="rule.gloss">rule</glossterm>
rendered, html : Use a rule to trigger an action. (rule is hot)
Ah! That goes against Bobs advice :-) 'Thou shalt not link to glossterm.'
Mmmm. I'm wrong by Bobs book, which is generally good advice.
Changing it to
<glossentry xml:id="rule.gloss">
<glossterm >rule</glossterm>
and it still renders the same.
I guess there are enough people making the same mistake!
Maybe there are scenarios where Schematron is more appropriate, but
I'm not sure.
If we asked, I'm sure there are quite a few 'options' that
could be checked with Schematron. Such as:
using <glossterm>Domain name</glossterm> without the
- glossterm.auto.link set to 1 in the customization layer.
- Mismatches between custom settings (use css, no css stylesheet)
[...]
Well, I fear, these parameters are only available in the transformation
step, not at validation time.
POssible user view... I care about the end to end process, xml through
to PDF/HTML/chm, not just the xml source?
With that view, transformation is part of the chain which needs checking.
Or are there just too many link options?
Maybe, maybe not. There have to be many link options as DocBook is
very general and users have different needs.
I wonder how many are becoming redundant as new technologies are
introduced?
That's a good question. As an example, I'm wondering if coref and
footnoteref are really needed and can be replaced by a simple xref.
But users might have some use cases for it.
I'm sure some would. Perhaps use the case of 'this will be deprecated in
v5' or whatever? How long should the older stuff be kept?
olink and xInclude spring to mind (though they have
slightly different purposes).
<glossterm linkend="NetAddr">network address</glossterm> and
<xref linkend='Netaddr'/>
and <link linkend="NetAddr">network address</link>
All have their purpose:
1. <glossterm linkend="NetAddr">network address</glossterm>
That's used when you want the "hot link" to be different from the
glossentry/glossterm text.
Then perhaps add that as a processing expectation (alternative)
to xref?
<xref linkend='NetAddr'>Net address</
etc.
2. <xref linkend="Netaddr"/>
That's the case where this doesn't really work as in glossentry is
no title. So xref can't automatically generate the linking text.
Bug? Feature?
Resolved :-) See above.
4. <olink ...>...</olink>
If you want to create a link across document bounderies, this is
the preferred method. However, it comes at a cost: you can't
validate it in the validation step. They can only be checked
during the transformation.
Or, as I do, expand the xIncludes then validate.
User choice I guess.
5. XInclude
I don't think they count as a "link" as the above elements.
It's resolved completely, but you know that already. :)
Sorry, I meant xlink
Actually, there are even more: I omitted XLinks and firstterm.
And the list goes on!
I don't think DocBook defines a 'preferred' processing model (if
you mean something different than the usual validation->transformation
steps).
But I've changed my definition of 'validate', to include xInclusion.
Is olink now deprecated?
I don't think so. It's more complicated than a simple xref, that's true.
However, it allows you to link to a resource across document bounderies
without destroying your validation.
That's a plus. though there is a cost.
You can please all of the people some of the time....
regards
--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
