Term keyrefs not being resolved

[David Goss]

I'm using <term keyref="myterm"/> throughout my document to reference glossary terms. One of the reasons I'm doing this is in case some of the terminology we are using changes.

For glossentries where there is only one glossterm, it works just fine. For example:

<glossentry>
    <glossterm>patient</glossterm>
    <glossdef>This is the definition for a patient</glossdef>
</glossentry>

If I use this code:

<p>The correct term is <term keyref="patient"/> and...</p>

I get

The correct term is patient and...

However, if the glossentry has multiple forms of the term, such as this:

<glossentry id="glossentry_odx_dkm_4n">
    <glossterm>patient</glossterm>
    <glossdef>This is the definition for a patient</glossdef>
    <glossBody>
        <glossAlt>
            <glossAcronym>participant</glossAcronym>
        </glossAlt>
    </glossBody>
</glossentry>

The term is not resolved, like so:

The correct term is  and...

This only seems to be happening with PDF output. Using webhelp, I'm seeing the term as expected. Here is how I'm including the glossary entries in my ditamap:

<!--glossary.ditamap:-->
<map>
 <title>Glossary</title>
    <glossref href="glossary/g_patient.dita" keys="patient"/>
</map>

<!--book.ditamap:-->
    <backmatter>
        <booklists>
            <abbrevlist print="yes" toc="yes"/>
            <glossarylist format="ditamap" href="topics/glossary.ditamap" print="yes" toc="yes"/>
            <indexlist print="yes" toc="yes"/>
        </booklists>
    </backmatter>

Also, despite having print="yes", I still do not see the glossary in the table of contents. It is also not printed.

[Jarno Elovirta]

Which DITA-OT version?

J

--
You received this message because you are subscribed to the Google Groups "DITA-OT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dita-ot-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Goss]

I'm using DITA-OT 1.7 (the version that ships with Oxygen 15.2)

[Radu Coravu]

I tested with both DOT 1.7 (Oxygen 15.x) and DOT 1.8 (will be released in future with Oxygen 16) and I obtained the same problem in the PDF output, the reference to the term was not expanded, no matter if the <glossentry> element had a <glossBody> or not.

I'm attaching the sample project I build using David's samples.

Jarno, should I add a bug for it?

[Roger Hadley]

In the old DITAOT sourceforge bug tracker, bugs item #3239041, was opened at 2011-03-23 about this issue. I added some comments to help it get resolved, but It sounds like it hasn't been fixed.

I resorted to using conkeyref in topics, rather than just keyref. That means in the glossentry file I have the following:

 

<glossentry id="glossentry_term">
  <glossterm id="glossterm">
    <term id="term">
      <text id="text_term">Clip</text>
    </term>
  </glossterm>
  <glossdef id="glossdef">
    <term id="def">A single media asset with video and/or audio, timecode, and associated metadata.</term>
  </glossdef>
</glossentry>

 

The keydef in the map points to the glossentry file.

 

In the topic I can pull in both term and definition with conkeyref:

<term conkeyref="advancedlogging/term"/>: <term conkeyref="advancedlogging/def"/>

 

-Roger

[Jarno Elovirta]

Radu, please add a bug report on this.

J

<testSamples.zip>

[Jarno Elovirta]

DITA 1.2 DTDs have a bug or an interesting feature. <glossref> element has default @print attribute value “no”. Thus, if you use it in PDF and don’t explicitly set print=“yes”, the <glossref> element will be filtered out early in the processing.

J

On 2 Apr, 2014, at 16:19, Radu Coravu <raduc...@gmail.com> wrote:

<testSamples.zip>

[David Goss]

Thanks for the tip. I went ahead and explicitly set print="yes" for all my <glossref> elements, and something interesting happened. All of the keyrefs are now resolved in the text and the terms appear as expected in the PDF. Each glossary entry also appears at the end of the PDF, however they are treated as chapter level (meaning each entry appears on its own page, and only starts on a recto. The invokation in the bookmap looks like this:

    <backmatter>
        <booklists>
            <glossarylist format="ditamap" href="topics/glossary.ditamap" toc="yes"/>

            <indexlist print="yes" toc="yes"/>
        </booklists>
    </backmatter>

[Jarno Elovirta]

Again, one of DITA’s interesting features. If you have

<glossarylist format="ditamap" href="topics/glossary.ditamap" toc="yes”/>

During map reference processing <glossarylist> element is actually removed and replaced with the map children of glossary.ditamap. However, due to processing rules, all the map children are renamed to the <glosslist> elements, thus you end up with

<glossarylist href="g_patient.dita" keys=“patient” … >

J

[Eliot Kimber]

I think I have an open issue to the effect that the map pull process should preserve or somehow record the class hierarchy of the referencing topicref in that case because otherwise you have lost vital semantic information, as in this case.

--
Eliot Kimber

[Radu Coravu]

So in David's case the <glossref> needed an extra " print="yes"" in order not to be filtered by the PDF processing. Adding a bug for this is no longer necessary, right?

From what I understand David's current problem is that each glossary definition appears on a separate page in the PDF but this might be the intended behavior and might be configurable with a PDF customization. The XHTML output also creates separate HTML pages for each glossary definition.

David, what would the desired behavior be for you? A single chapter-like division in the PDF containing all defined gloss entries listed one after the other and with no page breaks between them?

[David Goss]

David, what would the desired behavior be for you? A single chapter-like division in the PDF containing all defined gloss entries listed one after the other and with no page breaks between them?

Yes--that's what I'd like to accomplish. I want the glossary itself to appear in the table of contents, at the same level as chapters, and then the glossentries appear in sequence without page breaks between them. The XHTML output where the appear on separate pages seems to be good default behavior in my opinion, but I'm not sure that's really expected for a PDF. I've never seen a printed book with a glossary formatted that way.

I do have a very basic customization layer for FO output already setup. I have very little experience customizing the DITA-OT, so would appreciate it if you could point me in the right direction.

[David Goss]

I was given a workaround in email that works exactly as expected:

            <glossarylist>
                <mapref href="topics/glossary.ditamap"/>
            </glossarylist>

This resulted in a chapter-level glossary formatted as expected. It was placing the href in the glossarylist directly that seemed to case the issue.

On Thursday, April 3, 2014 8:20:37 AM UTC-4, Radu Coravu wrote:

[Julio Vazquez]

 I would expect that unless I specifically use print='no' that all content is included in PDF. I consider this a bug and should be fixed.

On Thursday, April 3, 2014 8:20:37 AM UTC-4, Radu Coravu wrote:

[Radu Coravu]

The DITA 1.2 specs for glossref states that print="no" is the default value for glossref (and the DITA 1.2 DTDs are compliant with this):

http://docs.oasis-open.org/dita/v1.2/os/spec/langref/glossref.html#glossref

print - Specifies whether the topic should be included in a print-specific rendition, such as PDF. On this element the value defaults to "no".

[Julio Vazquez]

The default described in the spec is counter-intuitive, especially when it comes to print-based output. Why was it done this way? I would actually file a bug against the spec because the base assumption everywhere except in things like keydef or navref is that the content is processed and printed. If I have a glossref in my map, I would expect output from it unless I took steps to filter it out.

I'm confused by the logic of this decision.