[libXext: PATCH] Fix id attributes, linkend and olinks

[Matt Dew]

>>> Shall I post all the other patches, (they all do the same thing) or put
>>> up the repos that people can pull or, since the other patches are of the
>>> same things, should I just push those?
>> No need to post hundreds of identical patches. So as long as they do
>> just change the ids.
>> No "while in there" changes.
>>
>> But please, fix the typo first: capitolization
>> I don't want anyone else making more typos than I do :-)

Noted. :)


>>
>> For reference inside the doc, would it not be more appropriate to use
>> xref or something?
>> I thought olink were for refrence across external documents? One
>> drawback of using olinks
>> is that the masterdb may or may not be there. There may be a
>> performance issue as well,
>> or other unforeseen side-effects. No need to use a bigger hammer than
>> necessary.


There were a couple small reasons that together made me think internal 
olinks were better.  Consistency, olinks everywhere therefore no 
confusion, and xref's generated ugly output. You can't define the link 
text, it pulls it automatically from the link destination.

Before 4.3, which is when I last looked into this,
this:
<xref linkend='sect2id'/>
would only generate link text 'The section called 'sectiontitle.' which 
I though was really ugly.

olink allowed us to define our own link text.

However, 4.3 allows us a little more freedom so i'll change my patches.

>>
>> Recall the for olinks to work, the docs need to be installed (as well
>> as masterdb). It is inconvenient
>> for local links to rely on that. No one will complain now, but
>> eventually if people get use to it,
>> and use the doc from their dev build only, the local links would not
>> work. Unless, of course,
>> there is some smarts in docbook to workaround the situation. have you
>> tried it?

I couldn't find any docbook support for that.

>>
> Not a good idea to use olink for local ref. You will always get, on the
> first build:
>
>     Error: unresolved olink: targetdoc/targetptr = 'dbelib/XdbeQueryExtension'.
>
> It cannot look in its own not yet generated targetdb to find the link.
> This is very annoying.
>> One suggestion for testing is to take some random sample of documents
>> and test the link actually works.

I've been doing that as I go.


thanks for the review,
Matt