OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: conref sequence issue, proposed rewording in spec

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

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

- 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]