[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] ITEM: Cross-references to Topicheads and ImplicitTitle-only Topics
On 4/7/09 9:55 AM, "Michael Priestley" <mpriestl@ca.ibm.com> wrote: > Why is it acceptable for href and conref to mean different things, but not > href and keyref? Conref is establishing a different *semantic* from href/keyref, namely a use-by-reference link, rather than a navigation relationship. Keyref/href are alternatives forms of addressing for establishing the same relationship, navigation. That is, conref/conkeyref are alternative forms of address for a single semantic and href/keyref are alternative forms of address for a *different* single semantic. The key is the nature of the relationship, not the form of address used. Or said another way, conref is a shorthand for having *different* element types, one for each existing element type, that mean only "use by reference". If DITA had such elements, there would only be href/keyref attributes because the linking semantic would be defined by the element type. Because DITA allows a single element type to convey two different core semantics, there have to be different pointing attributes to make the semantic distinction. If we had been able to come up with a syntax that allowed keyrefs where URIs are allowed, we would have avoided the need for keyref/conkeyref entirely but we determined that such a syntax would be too difficult to use, so we defined distinct attributes. In the case of elements like <term>, we added keyref= in recognition that href= would *never be a good idea* because it's not manageable (because it's a hard address, irrespective of whether it went through a topicref indirection or not) and it would be pointless to allow people to create unmanageable pointers when the whole point is to enable reuse of topics within multiple contexts. Xref in DITA has always been a problem because without late-bound, context-specific addresses there is no way to make it manageable when pointing to other topics. Even if DITA had *always* said that topicrefs act as indirections (which in some implementations they did), it wouldn't have helped because the problem is the href= itself, not the lack of indirection. Keyref= solves the problem by being late-bound, which *enables* the manageable use of indirection. The keyref facility requires that topicrefs act as indirectors, at least in some circumstances. Either they *always were* indirectors (and the spec failed to mention it) or they *are now* and therefore need to be for all uses of topicref from other elements (possibly modified by controls on the initial linking element). I think this is a very simple principle for which the processing implications can be clearly enumerated by applying the principle. That is, the question is "source element X is pointing to a topicref that has property configuration Y, what is the ultimate link target?" The answer should be arrived at by a purely mechanical process that is independent of the form of initial address. Cheers, Eliot ---- Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc. email: ekimber@reallysi.com <mailto:ekimber@reallysi.com> office: 610.631.6770 | cell: 512.554.9368 2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403 www.reallysi.com <http://www.reallysi.com> | http://blog.reallysi.com <http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]