This does not make it easier to explain conactions,
but the best we can do is make sure the terminology is unambiguous. For
example:
Specifically, the ambiguity of
source/target is one problem and explaining conref push is another. We should
not try to bundle conref push issues into a clarification of source/target
terminology. It makes the task much too difficult, and maybe
irresolvable. And I bet we probably write around conref vanilla vs.
conref push well enough already.
/Bruce
From: Park Seth-R01164
[mailto:]
Sent: Thursday, October 08, 2009
10:42 AM
To: DITA TC
Subject: RE: [dita] Conref
terminology: Referencing element and referenced element
I think the resolution was that the TC requests that the
author group consider making the terminology unambiguous.
The proposed terminology
(paraphrased):
The element with the referencing attribute (href,
conref, keyref, etc.) is always the referencing element, regardless of the
behavior of the reference.
The referenced element is the element specified in the
referencing attribute (or the resolved target of an indirect reference)
of the referencing element.
This does not make it easier to explain conactions,
but the best we can do is make sure the terminology is unambiguous. For
example:
When using conref pull (no conaction specified), the
referenced element replaces the referencing element.
When using conref push, the referencing element
replaces the referenced element.
(BTW, Don said specifically that he was sensitive to
making resolutions that impact arch spec activities.)
-sp
--------------------------------------------
seth park
information architect
Freescale Semiconductor,
Inc.
512.895.2463
