Re: [docbook-apps] Unresolved olink when generating target dababase

["Bob Stayton" <bobs@sagehill.net>]

Hi Jan,

The error message appears during the collection process only because one of 
the elements whose text is being collected includes an olink.  The term 
element in your varlistentry contains an olink.

Here is what is going on.

1.  The olinks collection process includes every element that has an id 
attribute, on the assumption that someone may want to link to any id from 
another document.  So when your varlistentry has an id, it is included in 
the target data.  If it has no id, the varlistentry is not processed to 
collect its target data.

2.  When the varlistentry is processed to collect its target data, part of 
the data is the link text that would be generated if it were the target of 
an xref.  Templates are applied to the term element to resolve the text to 
what it would be when output, and that text is saved in the target data 
element named <xreftext> in target.db.

3.  The first time the term element is processed for target text, the olink 
element is encountered, so the apply-templates processes the olink.  But the 
first time through, the target.db data is not yet populated, and so the 
template with match="olink" cannot find a <div targetptr="term">, and so it 
generates that error message.

4.  Since the olink did not resolve at that step, the xreftext for the 
varlistentry in the first pass does not have a resolved link, and so the 
collection process just outputs a <span class="olink"> around the olink's 
manually entered text.  That's what you get when an olink does not resolve.

5.  The first collection process continues, and then finds the section with 
id="term" and adds that to the data collection.   At the end, it writes out 
the target data that it has to target.db.

6.  The second time the target data is collected, again the varlistentry has 
an id so it is processed.  At the start of the process, the target.db file 
is opened and loaded into memory.  This time when the olink in the term is 
encountered, the target.db data has been populated from the previous run and 
has a div with targetptr="term", and so it generates a valid link in the 
xreftext. So that is why the second time the target data for varlistentry is 
<a href="#term class="olink"> instead of <span>, and it does not generate 
the error message.

So this situation comes up when an element that is included in the target 
data has an olink element it its text.  The first time the data is 
collected, you will get that error message.  As long as you collect the data 
first, and then run the processing to generate output, the olinks will 
resolve properly in the output.

Let me know if any of this is not clear.

Bob Stayton
Sagehill Enterprises
bobs@sagehill.net


----- Original Message ----- 
From: "honyk" <j.tosovsky@email.cz>
To: "'Bob Stayton'" <bobs@sagehill.net>
Sent: Monday, March 16, 2009 11:10 AM
Subject: RE: [docbook-apps] Unresolved olink when generating target dababase


> Dear Bob,
>
> results of my observations can be found in the enclosed ZIP file.
>
> My documentation is splitted into smaller parts, which are xincluded into
> the main XML document. Although olinks aren't necessary in this case, they
> are used due to XMetal's validation complaining if links with not existing
> IDs (in given file) are used.
>
> In the first step all xincludes are resolved. It is followed by 
> profilation
> and updating target dababase file. Profiled output was cleaned up, reduced
> to "minimum" and enclosed. In separate file there is command line, which 
> is
> used for updating target database. There are also three final database
> files. One of them is the result of processing if ID attribute on
> varlistentry element is removed, two next are with this attribute set. To 
> my
> surprise, they differs a little bit which gives me an answer why it 
> bahaves
> differently. I've already mentioned the most intersting observation when 
> the
> output differs between the first and second run the same command line. 
> There
> is really slight change which is out of my understanding (span -> a)...
>
> Thanks for your effort.
>
> Jan
>
>
>> -----Original Message-----
>> From: Bob Stayton [mailto:bobs@sagehill.net]
>> Sent: Friday, March 13, 2009 9:32 PM
>> To: j.tosovsky@email.cz
>> Subject: Re: [docbook-apps] Unresolved olink when generating
>> target dababase
>>
>> Hi,
>> I'm not able to duplicate this problem.  Can you send me a
>> short complete
>> example document that includes the olink and the target element?
>>
>> Bob Stayton
>> Sagehill Enterprises
>> bobs@sagehill.net
>>
>>
>> ----- Original Message ----- 
>> From: <j.tosovsky@email.cz>
>> To: <docbook-apps@lists.oasis-open.org>
>> Sent: Friday, March 13, 2009 3:37 AM
>> Subject: [docbook-apps] Unresolved olink when generating
>> target dababase
>>
>>
>> > Hello Everyone,
>> >
>> > I've found strange bahaviour if my XML file is processed.
>> It contain
>> > olinks, so in the first step I create target database.
>> Regardless the used
>> > stylesheet (html/chunk.xsl or html/docbook.xsl), I am
>> getting in one
>> > special case an error mesage: Error: unresolved olink:
>> targetdoc/targetptr
>> > = '/myID' . Rest of olinks work fine. This ID is present and after
>> > standard transformation (not only collecting xref targets)
>> everything
>> > works fine. I've found test case when this message appears
>> - it can be
>> > determined by the following xpath:
>> //varlistentry[@id]/term[olink]. If id
>> > attribute of varlistentry element is removed, message
>> disappears. The most
>> > interesting thing is, that this problem is detected only
>> for the first
>> > time when target database is refreshed by the another
>> source XML file (in
>> > my case each transformation replace the same database
>> file). In the second
>> > run with the same file everything is Ok...
>> >
>> > It is probably cosmetic issue only, but I am reporting it
>> as there could
>> > be broken something with deeper impact on something else.
>> >
>> > Jan
>> >
>> > PS: Detected with XSL version 1.73.2, but in 1.74.3 still present.
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail:
>> docbook-apps-unsubscribe@lists.oasis-open.org
>> > For additional commands, e-mail:
>> docbook-apps-help@lists.oasis-open.org
>> >
>> >
>> >
>>
>