conref sequence issue, proposed rewording in spec

[Michael Priestley <mpriestl@ca.ibm.com>]

We have an interesting edge-case issue.


1. The spec says that conref can target
more specialized content, as long as it gets generalized during the resolution
process:

>In the preferred approach, a processor
resolving a conref should tolerate
>specializations of valid elements
and generalize elements in the content fragment
>as needed for the referencing context.
 

2. If there are multiple conrefs in
a chain (eg topic1 to topic2 to topic3) we don't say which order to resolve
it in:

>If the target element has a conref
attribute specified, the above rules should
>be applied recursively with the
resolved element from one  source/target combination
>becoming  one of the two  elements
participating in  the next source/target
>combination.

3. And here's the issue: the sequence
does matter if you have generalization happening in that sequence:

Example: 
- topicA and topicC use the ui domain
- topicB does not use the ui domain

topicA conrefs a paragraph from topicB
which punts to a paragraph from topicC. The final target paragraph contains
uicontrol elements, which are valid in topicA and topicC but not valid
in topicB

If we start from the source side, then
topicA->topicB pair gets resolved to topicA, which allows uicontrol,
and then the topicA->topicC pair gets resolved to topicA, both of which
allow uicontrol: net result, we still have a uicontrol at the end of the
resolution process.

If instead we start from the target
side, then the topicB->topicC pair gets resolved to topicB, in which
uicontrol is not allowed, so it gets generalized to ph. Then topicA->topicB
is resolved, but the uicontrol is already gone: net result, we no longer
have uicontrols, only ph's.

4. Proposed resolutions: We either document
the sequence (start resolving pairs starting from the source), or we say
that the context of the original calling element determines the validity
for any element resolution in the chain.

Differences between the proposals:
- if we document the sequence, we may
be introducing assumptions about the processing model. We want to minimize
that, on the other hand we need to have compatible results across different
processing models, so there does need to be some agreement on the result.

- if we don't document the sequence,
the decision may appear arbitrary

5. Anticipating a compromise wording
- suggest adding:

>>>
The result should preserve without generalization
all elements that are valid in the originating context, even if they are
not valid in an intermediate context. For example, if topicA and topicC
allow highlighting, and topicB does not, then a content reference chain
of topicA->topicB->topicC should preserve any highlighting elements
in the referenced content. The result is the same as if the conref pairs
are resolved recursively starting from the source element.
>>>


Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25