In a large dita document set, can someone explain how to associate a unique profile condition set with each ditamap?

[rwmm415]

In Brief: I am looking for an automatic way to bind a unique conditional profile to each ditamap in a set of related maps.

We publish several versions of a large technical user guide in Oxygen. All of the dita content (thousands of files) resides in a single directory. The make up of each version of the guide is determined by its ditamap. A large percentage of the dita files are shared between the versions. Some of the shared dita contains conditional profiling to customize the content to the document's "context" when it's necessary to do so. All of this is already implemented and it seems to work well for both PDF and WebHelp build scenarios.

What I don't like about the current setup is that each time a ditamap is opened for one of the guide versions, the writer has to remember to use the Oxy menu commands to select the appropriate profile condition set for that version of the guide. If the the wrong condition set (or none) is selected you'll get incorrect display of content in editor Author mode and incorrect build results. I generally remember to check this when I open a new map, but that's because I set this system up in the first place. The other writers and maintainers are unclear on why this matters and often forget to do it. They'll get these problems, forget to check the profile setting and then contact me. I am seeking an AUTOMATIC way to bind the proper condition set to each ditamap -- surely, there's got to be a way to do this.

Let me quickly run through the methods I have tried already:

CONFIGURING A FILTER IN THE TRANSFORM SCENARIO. Yes, you can specify a 'ditaval' file on the filter tab so that the proper profile conditions are set at build time. This requires creating multiple duplicate scenarios that differ only in the ditaval selection -- though this can probably be avoided by having a single scenario with a ditaval selection specified using a substitution editor variable in the filename. (I haven't tried this yet.) However, the shortcoming of this approach is that the condition set is not established in the Oxy editor so that the writers don't get the benefit of a WYSIWG view that reflects the current profiling conditions. So, this method is not a complete solution.

PROFILING CONDITION SETS SAVED IN A PROJECT FILE (XPR). It is often suggested that you can save profiling condition sets into the project file to ensure they are automatically associated with the maps in that specific project. Yes, the project file retains all possible condition settings (Product=[EUR/ASIA/NA] in this case) and whatever selection was the last used in the project. But all versions of our user guide are part of a common project. Having multiple project files would require the writer to switch between them to work on different versions of the user guide. This would be no less of a burden than remembering to select the profile condition set when opening a user guide map (what we currently do).

BRANCH FILTERING. This approach (embedding a <DITVALREF> in the map) is the one that ought to do exactly what we need -- associate a condition set with a ditamap. It fails for us in two ways. First, you can't apply the <ditavalref> tag at the root level of the map. Each of our guides is defined as a <bookmap> containing a list of <parts>. The bookmap won't accept a <ditavalref> tag, so that forces you to apply them to the individual <part> sections. This is a minor bit of redundancy and I can live with it.

The bigger problem occurs during the build. The transform generates thousands of duplicate topic ID errors (a pair of errors for every topic ID in the guide, apparently). I read another post in this forum that suggests this is an artifact, a result of the way that conditional profiling is implemented in Oxygen. The build should succeed anyway and the errors can be ignored. But we have repeatedly tried to emphasize to our writers the importance of having "clean", zero-error builds when publishing, and to stop the practice of ignoring the error logs. So, we would like to avoid this approach if possible.


EXPRESSING PROFILE CONDITION SETS AS DITAVAL. One final concern I've wondered about: Have I formatted my ditaval correctly? You can import ditaval files in Oxy to apply their profile condition settings, but you can't export your current profile to ditaval, AFAIK. You're on own to construct a ditaval file that is equivalent to the current profile setting. Our use of profiling is quite simple. We use the predefined 'product' attribute and have given it the possible values: [EUR/ASIA/NA]. So, for example, if I select the EUR profile through the menu command, it sets the condition 'product = EUR'. Based on examples I could find online, I have tried to express this setting in a ditaval file as follows, though I still not certain this is correct.

<?xml version="1.0" ?>
<val>
<prop action="exclude" att="product"></prop>
<prop action="include" att="product" val="EUR"></prop>
</val>


In summary, the two questions are:

(1) How can I automatically bind unique condition sets to each ditamap in a set of related maps on opening?
(2) Have I expressed the simple "product=[ A | B | C ]" condition setting correctly as ditaval XML in the example shown above?

Best regards,
Robert @ Hoffman MarCom