Hi, Jarno pointed out that the following case is not specifically addressed in the 1.3 language. Ignoring any keys or resource names, the question is - how do the branches interact in the following scenario? <mapref href= > <ditavalref href= > <ditavalref href= > </mapref> And in other.ditamap: <map> <ditavalref href= > <ditavalref href= > ...topics... </map> The spec says that having <ditavalref> as a child of mapref is equivalent to having one at the root of the map - each would result in a new copy of the full map. But it doesn't address the situation where one is present in each spot. With this specific example, I think the author's intent is to have the ones in <mapref> create an implied group. So, the entire map would be filtered for novice, and the entire map would be filtered for admin; within each of those branches, you would have sub-branches for OS. As a result, the fully resolved branches would become: novice-osX novice-linux admin-osX admin-linux If that is the case, then the original mapref could be rewritten as follows, to get the same result: <topicgroup> <ditavalref href= > <ditavalref href= > <mapref href= > </topicgroup> The only other way this could resolve is to state that the ditavalref elements all become peers. For this example, the result would be 4 branches - one each for novice, admin, osX, and linux. There may be use cases where this is what you want (add a branch for windows?). However, I think situations like the one here will be more common. The sub-map is more likely to take into account all locally-defined values for one axis, and the map reference is more likely to add unrelated categories. Thoughts? Robert D Anderson IBM Authoring Tools Development Chief Architect, DITA Open Toolkit (
http://dita-ot.sourceforge.net/ )