[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Deprecating @copy-to
I wanted to follow up on Stan's remarks about @copy-to causing multiple copies of a topic in the HTML result and this being a problem for search. This is a larger problem than just @copy-to—it occurs in any situation where the same topic is used more than once and those uses require different rendered results or you simply choose to produce separate result artifacts for each use. In particular, the use of key scopes and branch filtering can result in this case regardless of the use of @copy-to or @keys on the topicrefs involved: each different use of the same topic could reflect different filtering results or different resolved key references and therefore the rendition of the topic in each use needs to reflect those differences. The practical problem for the implementors of HTML-type outputs is how to handle this case: through generation of separate HTML files, one for each use that results in a different rendered result, or through display-time dynamic mechanisms embedded in a single result file. Today the Open Toolkit takes the first approach, mostly, which is easy to implement, but many users would really rather have a single-file, dynamic rendering solution. There is also the problem with tracking user navigation in such a case, either as a result of arriving at a rendered topic via search or navigating to it through some sequence of navigation links. Both have important user interaction implications and present interaction design challenges. These issues are inherent in doing reuse and are not directly related to the use of @copy-to or keys. The issues are simply an unavoidable side effect of delivering re-used content to multi-file outputs like HTML. Removing @copy-to and using keys in their place does not actually do anything to address these issues, because these are delivery-in-the-face of re-use issues, not source markup issues. The issues have always been present in DITA since 1.0 but it's only been with branch filtering and key scopes that the challenge has become blindingly obvious because there are more opportunities for re-used topics to require different renderings for different uses. I wrote a blog post about this issue recently: http://drmacros-xml-rants.blogspot.com/2016/05/delivering-html-from-dita-in-face-of.html#links Cheers, Eliot ---- Eliot Kimber, Owner Contrext, LLC http://contrext.com From: dita <dita@lists.oasis-open.org> on behalf of Jim Tivy <jimt@bluestream.com> Date: Monday, June 6, 2016 at 9:23 PM To: Eliot Kimber <ekimber@contrext.com> Cc: dita <dita@lists.oasis-open.org> Subject: Re: [dita] Deprecating @copy-to What I was saying is ?ditaScope="foo" would be defined by DITA to have the meaning that it means reference that scope within the current map. On Tue, May 31, 2016 at 7:43 AM, Eliot Kimber <ekimber@contrext.com> wrote: I don't understand this comment: |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]