... We just ran your project pretty much as you have it above, in DITA2Go, and it worked fine. Our bookmap: <?xml version="1.0" encoding="UTF-8" ?>

I realized a mistake I made and wanted to write it up in case it helps someone avoid making the same mistake. We're currently using a filesystem/svn to manage

Hi Julio! Yes, I've tried that among others such as: -Including the reference (either topicref or mapref) in the frontmatter, backmatter and as a chapter.

Thanks for the clarification Eliot!

It is not an error to have multiple definitions for the same key, although processors may choose to report the condition for diagnotistic purposes. There are

Jarno, Yes. I was under the impression that the key value was global in the document. -Mica

Hi CT, How are you processing the map? I've not seen this behavior. Have you tried using a mapref instead of a topicref? Julio J. Vazquez SDI Global Solutions

Hi. Is there a reason that the software (and programming) domain is not available in a Machinery Task topic? Thanks, Reuven Weiser Suite Solutions

Mica, Do you mean that the example below should result in an error condition because there are duplicate key definitions? Jarno

Jarno, Key names are global, and that should fail, no? -Mica

The spec at http://docs.oasis-open.org/dita/v1.2/os/spec/non-normative/interoperability-considerations.htmlsays The DITA specification does not require

Hi Aliza, Thank you for the advice. I removed mkdir and the directory was created anyway, so far so good. I moved the properties inside ant, but that did not

I've got a build file that does this. First, after each target like your target1 below, I have a line that copies file="name_of_map.pdf" to another name so I

Using tips from Kevin's post and also from some offline advice that Jarno sent to Kris, I wrote the following XSL overrides that produce the effect that Kris

... Good point. We first read all the maps referenced directly (while filtering for ditavals). That gives us what we need to identify the correct keydefs to

The spec *cannot* allow the order of conref and keyref processing to result in different final results: that would be very very wrong. If you think the spec

No, because the effective key bindings are defined before conrefs or keyrefs are resolved. Only in cases where you have something like

Wouldn't changing the order of conref/keyref resolution sometimes change how a keyref gets resolved when a map uses conref?

I don't have the exact numbers at hand right now, but earlier this year I noticed that if the order or keyref and conref makes almost a three fold difference

Hi Pawel, Here is one way. 'args.input' and 'output.dir' cannot be set on the command line, or this, and all other methods, will not work. ...