Re: keydef in bookmaps?


Dave C
 

Hi,

I have been having a similar problem. I am trying to pass a part number and printing date from the bookmap to a static boiler.dita file. In some of my books it works fine every time, in others it fails every time, except for the first time it is run. On all the failing cases, I get the following error:

keyref:
[pipeline] java.lang.NullPointerException
[pipeline] [DOTJ047I][INFO] Unable to find key definition for keyref="bookpartno", href may be used as fallback if it exists. Please make sure the key name is correct.
[pipeline] [DOTJ047I][INFO] Unable to find key definition for keyref="date", href may be used as fallback if it exists. Please make sure the key name is correct.

I have actually copied the entire <frontmatter> from a bookmap that always works and pasted it into a bookmap that always fails and there is no change in the outcome.

Any thoughts?

Thanks,
Dave C.

--- In dita-users@yahoogroups.com, Eliot Kimber <ekimber@...> wrote:

On 1/15/10 3:48 AM, "nigelfrance" <nparker@...> wrote:

I'm trying to use conkeyref in conjunction with keydef/keys to provide an easy
method to use variable strings.

I have created a variables.xml topic that contains:

<topic id="id087ELM0405Z">
<title>Variable Definitions</title>
<body>
<p><ph id="familyname">Brand Name</ph></p>
<p><ph id="productname">My Product Version 1</ph></p>
<p><ph id="productnameshort">Product V1</ph></p>
</body>
</topic>
You don't need conref just to get strings, you can put the strings in the
key definitions then use just the key. E.g., in a map document:

<keydef key="familyname">
<topicmeta>
<keywords>
<keyword>Brand Name</keyword>
</keywords>
</topicmeta>
</keydef>

And then in your topic:

<ph keyref="familyname"/>

I just tested this with the latest 1.5 Toolkit and it works.

But in any case, conrefs should work everywhere consistently--the Toolkit
does conref resolution before it does any other processing, meaning that the
final-stage transforms, the ones that produce a specific output, are given
data that reflects conref having already been resolved.

I reference this topic in a BOOKMAP's frontmatter as:

<keydef keys="variables" href="rVariables.xml"/>

From within *most* topics, I can include a variable with, for example:

<ph conkeyref="variables/productname"/>

This all works as expected.

However, within topics in the frontmatter of the BOOKMAP (ie the preface), the
variables are not being resolved and nothing appears in the output.

This sounds like a bug to me, but any ideas as to how to fix this ?
It's either bug or user error, although it's hard to imagine what the user
error could be.

One test would be to generate HTML and see if you get the same result. Also,
check the toolkit log to see if it says anything about unresolvable key
references.

If you can put together a small failing test case I'll be happy to take a
look at it off list.

Cheers,

Eliot



On 1/8/10 2:45 PM, "nigelfrance" <nparker@> wrote:

Hi Eliot,
Got it now, thanks.
Cool. The way you're using keys is one of the main use cases that drove the
key design, that is, replacing conref for getting variable or
context-dependent terms and phrases.

Note that if you add an @href to your keydef that points to e.g., a glossary
entry topic, then the <keyword> element will both reflect the keyword
defined in the keydef and be a navigable link to the target topic.

Cheers,

E.


In my bookmap I have:

<topicref href="testkeys.ditamap" format="ditamap"/>

Where testkeys.ditamap contains:

<map title="DITA Topic Map">
<keydef keys="productname">
<topicmeta>
<keywords>
<keyword>My Product Version 1</keyword>
</keywords>
</topicmeta>
</keydef>
<keydef keys="shortproductname">
<topicmeta>
<keywords>
<keyword>My Prod V1</keyword>
</keywords>
</topicmeta>
</keydef>
</map>

To reference these keywords:

...an overview of <keyword keyref="productname"/> (hereafter abbreviated to
<keyword keyref="shortproductname"/>).

Thanks again.


On 1/8/10 11:36 AM, "nigelfrance" <nparker@> wrote:

I can't, however, seem to get it to work when I put the keywords in a
separate
file and use href:

<keydef href="testkeys.ditamap" keys="productname" format="ditamap"/>
This is your problem. You want to use a normal topicref to include the map,
e.g.:

<topicref href="testkeys.ditamap" format="ditamap"/>

Where testkeys.ditamap then contains the keydef for "productname" as from
your working example.

That is, you're pulling in a map that contains a set of key definitions,
not
using the map's metadata as the key definition.

Cheers,

E.


and in testkeys.ditamap (seems I need a ditamap to get topicmeta, whereas
your
example was a .dita?):

<map title="DITA Topic Map">
<topicmeta>
<keywords>
<keyword>Product Name in DITAMAP</keyword>
</keywords>
</topicmeta>
</map>

In this case, there are no processing errors, but the keyword doesn't
appear
in the output. What am I missing?

I sometimes use a lot of variables in a document and it seems like I'd
need
to
include a lot of markup, with keydef/topicmeta/keywords/keyword repeated
for
each variable. Using the external form, I'd have less markup in the
bookmap
but would need to maintain a separate ditamap file for each keyword?

It would be nice to be able to do something like:

<keydef keys="productname" keyword="My Product Version 1"/>
<keydef keys="shortproductname" keyword="Product V1"/>
...

Is there any way to achieve this?



On 1/7/10 3:30 AM, "nigelfrance" <nparker@> wrote:

Hi,
I notice that the keydef element that is new in DITA-OT1.5 is only
available
in ditamaps, not bookmaps. Was this a deliberate omission? Looks like a
nice
feature and to me it would be just as useful in bookmaps as ditamaps.
You can use <keydef> in Bookmaps, just not as a direct child of
<bookmap>.
For example, you can have <keymap> within <frontmatter>.

Note that any topicref or topicref specialization should be able to
define
keys (unless the designer of the specialization has explicitly disallowed
they @keys attribute, which would be an odd thing to do).

The <keydef> element is just a convenience in that it sets the default
value
of the new attribute @processing-role to "resource-only", indicating that
<keydef> elements, by default, serve only to define keys and do not
contribute directly to the navigation hierarchy.

For example, this keydef element:

<keydef
keys="key-01"
href="mytopic.dita"
/>

Is exactly equivalent to this topicref element:

<topicref
keys="key-01"
href="mytopic.dita"
processing-role="resource-only"
/>

Any topicref can define keys, so you can add keys to existing topicrefs
in
existing maps--you don't have to use new topicrefs just to define keys,
although that may be good practice for other reasons (such as making it
easy
to find by inspection what keys have been defined in a given map).

In my map specializations I like to create a separate topicref
specialization named "keydefs" whose sole purpose is to hold <keydef>
elements for ease of organization.

One common practice is to put all key definitions into separate map
documents that contain only keydefs, and then include those key-defining
maps into main maps. This helps to keep key definitions concentrated in
one
place, making them easier to find and manage and possibly making it
easier
for tools to manage keys more effectively.

When using keys, one authoring challenge is knowing what keys are
available
for use by key references. In the absence of a key-aware CMS or link
management system, putting all key definitions into separate maps with
well-known locations and/or naming conventions or into consistent places
within maps will go a long way toward making the use of keys more
manageable.

Keep in mind too that there is an unavoidable processing challenge with
keys, which is that the same key name can be defined any number of times
within a map tree, but only the first one in a given map tree is
effective,
in a breadth-first traversal of the map tree.

This means you can't know what the set of available keys is or what the
effective definition of a given key is without first establishing a root
map
context, building the map tree, and constructing the "key space" for that
map tree.

While you would ultimately like to depend on tools to do this for you
during
authoring, in many cases authors will have to find keys by inspecting the
maps they are working with. Having key definitions scattered about the
maps
makes it harder to do this manually. If all key definitions are collected
into consistent places within maps, authors can be reasonably certain
they've found the effective definition of a given key within a given map
tree.

Since one of the points of keys is that the same key name may have
different
bindings in different use contexts (different map trees), it would be
missing the point of keys to require that a given key name have exactly
one
definition in a given information set, so you can't rely on simple key
name
uniqueness.

Depending on the nature of the information, another technique is to
define
the set of key names separately because the key names reflect the things
being documented, e.g., API class and method names, tagnames, part
numbers
or names, glossary terms, etc. That is, for a given information set there
may be a set of well-known and largely invariant key names that can be
defined and documented separate from the definition of those keys in
maps.
Authors then blindly use the keys in references, confident that someone
else
has taken care of creating the appropriate key definitions for different
contexts.

Note that the DITA For Publishers project includes a general DITA link
management Java API and some command-line utilities built using that
library, including a "map bos report" tool that processes a root map and
reports all the files ultimately used from that map as well as the key
space
represented by that map (that is, the set of key effective key
definitions
and their bindings).

The package is available from the files area of the DITA4Publishers
project
on SourceForge:

http://sourceforge.net/projects/dita4publishers/files/dita4publishers/2010->>
0
1-04/d4p-api-and-tools-2010-01-04.zip/download

The intent of this code is, in part, to enable more complete support for
keys in authoring tools by providing a general-purpose key management
facility. That is, the library provides the service of constructing and
providing access to key spaces and doing key resolution on demand. In
theory, by providing a public API for DITA-specific link management, it
would make it easier for DITA-aware authoring tools and processors to
integrate with DITA-aware content management and link management systems.
At
least that's the idea. In any case, I'm trying to lower the cost of using
keys and key references by providing some base infrastructure for
key-related processing.

Cheers,

Eliot
--
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770
www.reallysi.com
www.rsuitecms.com
--
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770
www.reallysi.com
www.rsuitecms.com
--
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770
www.reallysi.com
www.rsuitecms.com
--
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770
www.reallysi.com
www.rsuitecms.com

Join main@dita-users.groups.io to automatically receive all group messages.