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

[Thomas Schraitle <tom_schr@web.de>]

Hi,

> Thomas Schraitle wrote:
> 
> > 
> > Not glossary target, xrefs to glossentrys.
> 
> Sorry, I was inexact.

Not a problem. :)


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

I was wrong, xref works as expected. Probably my English to German decoder 
does not work correctly today. ;)
 
 
> [...]
> > 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.

Well, depends how you define it and where you draw the line:
I prefer to have a distinct, stable validation step which is not "diluted" 
by some (XSLT) transformation checking, at least as much as possible. With
this "model" I can validate my document without the need of transforming it
into different formats. And I can see it *directly*, if something goes wrong.

However, with RELAX NG and Schematron you get the best of both worlds: the
grammar based checking from RELAX NG and the rule based checking from Schematron.


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

Don't ask me, I'm not the maintainer. :-)
 

> >> [...]
> > 
> > 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</

Well, for this case, there is link. :)
Maybe the whole confussion comes also from different terms? Cross 
references are internal and links are a more general term (at least
to my understanding of these two words, correct me if I'm wrong).


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

Perfect! :-)


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

Hmn, I'm not sure what you mean. Do you use olinks instead of XIncludes?


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

Ahh, ok.


> > Actually, there are even more: I omitted XLinks and firstterm.
> 
> And the list goes on!

Well, don't forget the poor attributes xreflabel and xrefstyle... ;-)


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

That's perfectly ok. :)


> [...]

Tom