Tests setting of effective key scope and resource names using branch filtering when there are nested scopes and topicrefs.
Tests the effect of using <dvrKeyscopePrefix> and
<dvrResourcePrefix> when there are nested key scopes.
The specification is potentially ambiguous about what the correct behavior is in this case
for key scope prefixes and suffixes, in that it could be read as requiring that key scope
prefixes and suffixes be propagated to descendant key scopes if you only look at the
architecture specification. But if you look at the reference entry for
<dvrKeyscopePrefix> it makes it clearer that the prefix only
applies the scope names on the filtered branch. That is also the only sensible behavior as
otherwise qualified key references to scopes within the scope of the filtered branch would
be impossible to author. (This feature also makes it clear that having nested filtered
branches that both apply key scope qualifiers is probably not something you should do in
practice unless you know exactly what you're doing and why).
This test case has two branches, one without a @keyscope attribute and one
that defines a @keyscope attribute. In both branches there is a reference to
a <ditavalref> element that specifies a key scope prefix and a
resource name prefix.
Within each branch is a child topicref that defines a @keyscope of
"child-01".
The question is: "What is the effective key scope of the child topicref following application of branch filtering rules?"
The key scope prefix is "ksPrefix-" in both branches.
@keyscope values on the branches. Without different
@keyscope values you could have one branch with two
<ditavalref> elements.In both cases the effective key scope of the child scope should be "child-01" (that is, the parent scope's prefix should not be added to the child scope name.
The requirements for resource and key space name modification are defined in clause 2.4.4.4 Branch filtering: Impact on resource and key
names, as well as in the reference entry for
<dvrKeyscopeSuffix>.
<dvrKeyscopePrefix>- Enables a map author to specify a prefix that is added to the start of key scope names for each key scope in the branch. If no key scope is specified for the branch, this can be used to establish a new key scope, optionally combined with a value specified in
<dvrKeyscopeSuffix>.
Here, the phrase "each key scope in the branch" means "all the key scope names on the branch's @keyscope attribute, if specified", not "all the scope scopes descending from the branch".
For map branches that are implied by <ditavalref> elements, the value of the<dvrKeyscopePrefix>element contributes to the effective key scope names of the branch. The effective key scope names start with the value of the<dvrKeyscopePrefix>element. Note that if the branch as authored does not specify a@keyscopevalue, specifying<dvrKeyscopePrefix>(without also specifying<dvrKeyscopeSuffix>) results in the branch establishing a key scope whose name is the value of the<dvrKeyscopePrefix>element. The full key scope names also will reflect the value of a<dvrKeyscopeSuffix>element if one is specified, regardless of whether the branch as authored specifies a@keyscopevalue.
This makes it clearer that the prefixes (and suffixes) only apply to the filtered branch and not descendant scope names.
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 OT 2.2.3 | Pass. All links are resolved to the correct locations. | |
| DITA OT 2.2.2 | Fail: Only the link branch tr-branch-02 is resolved (the branch with the
explicitly-specified @keyscope attribute). The other links do not
resolve. |
The 2.2.2 OT propagates keyscope prefixes to descendant scopes. The 2.2 2 OT does not use the prefix or suffix as the key scope when no @keyscope is specified. |
| oxygenXML 18 beta build 2016031809 | Pass: Key references are resolved correctly. Pass: Key reference creation dialog includes the augmented scope names as selection options for qualified key names. |
There's no obvious way for the editor to reflect the fact that a topic is used in two different scopes and that navigating to it as used in one scope is a different result than when navigating to it as used in another scope. Doing a "search references" on the re-used topic does correctly reflect the places where it is used. |
| oXygenXML 17.1 | Key references are not resolved: reports the keys as not defined. Key reference creation dialog does not reflect branch-filtering defined scopes, no way to select key reference to post-filtering key scopes. |
Looks like oXygenXML does not take branch filtering into account when constructing its key spaces. |
| XMetaL 11 | Fail: The key spaces shown in the Key Space Manager do not reflect the branch filtering prefixes. | |
| XMetaL 10 | Fail: The key spaces shown in the Key Space Manager do not reflect the branch filtering prefixes. |