Good morning and happy conref...
I wanted to raise a comment that Eliot made in the latest review for discussion at the TC. Specifically, about this language:
"As with @conref, if the @conrefend references a more specialized version of the referencing element, applications should generalize the target when resolving."
Eliot recommends removing this rule: "I've never liked this particular rule because it assumes a particular processing result, namely literal generation of new DITA source. Generalization is only necessary if the resolved result is goingto be processed using grammar-aware processing, otherwise, there's not reason at all to do it."
To make the rule a little clearer before we discuss – an example of this rule in action would be a list item that uses conref to pull in content from a step. This is legal, because step is a more specialized list item; the rules of specialization say that step can limit what went into a list item, but cannot expand it, so any base element in the step is allowed in the list item. For example:
<li conref="mytask.dita#task/step"></li>
....
<step id="step">
<cmd>Sample step here<cmd>
<info>It shows how things work</info>
</step>
In this case – resolving the conref pulls a step into a basic task that would not otherwise allow a step. The generalization rule says that the step element should be generalized – turning the step into a list item, the command into a phrase, and the info into a division. The generalized result would be:
<li>
<ph>Sample step here</ph>
<div>It shows how things work</div>
</li>
If the rule is removed, there would be no suggestion to generalize the content. The only impact I can think of is that a common rendering tool might have extra rules for step, so that you end up rendering something odd in a normal topic that wouldn't normally be allowed or looks out of place. But – I think even using conref like this is such an uncommon case that it is worth considering whether this rule is useful.
Thanks,
Robert