Re: [docbook-apps] link linkend xlink:href olink and xinclude, v5

[Dave Pawson <davep@dpawson.co.uk>]

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