Uses key scopes with topicsetref.
<topicsetref>:<topicset> specifies a key scope and the
<topicsetref> does not.<topicset> does not specify a key scope and the
<topicsetref> does.<topicset> and <topicsetref>
specify a key scope.In all cases the key scopes should be preserved. The implication of the
<topicsetref> specification is that references to topic sets should
be treated like other map-to-map references, which implies that the same semantics as for
references to maps should apply, namely that any scope names defined on the referencing
element are combined with scope names on the referenced element to create a single key scope
with multiple names.
If a processor treats a <topicsetref> as a literal use-by-reference
such that the reference is completely replaced by the referenced
<topicset> element then it is likely to not preserve the scope
names from the <topicsetref>.
This test consists of two maps: Map A and Map B.
Map B defines two topic sets, one with a key scope and one without.
Map A has three topicset references: one with no scope that references the no-scope topicset, one with no scope that references the topic set with a scope, and one with a scope that references the topic set with a scope.
Within the topic sets are topics that include key references to the unqualified keys defined within the topic set.
Within Map A are references to topics that have scope-qualified key references to the keys defined within the topic set, using both the scope names from the topicset reference and from the topic set. All the links should resolve.
The DITA 1.3 specification is silent on the explicit implications for key scopes on topic set references. However, treating them like other map references seems like the most reasonable (and most useful) interpretation.
If this interpretation is used, then all the key references in all the topics should resolve.
General rules for map-to-map references and key scopes: 2.3.4.2 Key scopes.
The <topicsetref> element: 3.3.2.7 <topicsetref>.
Describe the results of running the tests with different processors. Include the processor version and option details so that others can reproduce your tests.
| Processor | Test Result | Notes |
|---|---|---|
| DITA Open Toolkit 2.2.4 |
HTML: The key scopes cause the OT to generate references to new filenames for each use of the topicset but the topicset itself is not processed as part of the generation of the referencing map's topics, so there is a mismatch between the references to the topics in the topicset and what is actually generated when the referenced map is processed separately. PDF: The topicsets are reflected in the output as expected but none of the cross references are correctly resolved. However, this could be a more general problem with scoped key resolution in the PDF2 transform. |
The behavior the OT HTML transform points up one essential problem with the
topicsetref mechanism: it presumes that the referenced topic will be rendered
separately for HTML-type outputs but there's no defined way to associate the key
spaces with the refering and referenced maps. The only rational implication is that
all the maps are processed together but the OT does not behave that way. That is, there should be no difference in the rendered result for HTML or PDF in terms of what links to what or what the effective navigation flow is once the topicsets are integrated with the referencing navigation structure, but the current OT implementation definitely does not ensure that for HTML output. |
| oXygenXML Editor 18 beta | Several issues:
|
The rules for combining the scopes of the topicsetref and topicset are not explicitly defined in the DITA 1.3 specification so Oxygen's behavior is arguably correct. |
| XMetaL 11 | Not tested | |
| FrameMaker 2015 | Not tested | |
| ditac 2.5.x | Not tested | |
| DFST Link Manager 0.9.x | Not tested |