[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Implementation Question/Spec Clarification: Implication of redundantchunk="to-content"
Consider this map: <map> <topicref chunk="to-content" href="topics/higher.dita"> <topicref chunk="to-content" href="topics/lower.dita"/> </topicref> </map> If I process this map with the current 1.5 milestone release, I get *two* HTML pages in the output, one for higher.dita and one for lower.dita. However, the behavior I *wanted* was that I get one HTML page in the output, reflecting the content of higher.dita and lower.dita. My question: is my expectation justified by either the current spec or the intent of the Architects? My expectation based on my reading of the spec and on what makes sense to me is that the highest-level specification of @chunk to-content governs and all subordinate to-content values (if not all @chunk values) are ignored, meaning if I say "to content" I mean to-content for the entire tree. I suspect that the current Toolkit behavior is just a silly bug but @chunk semantics are complicated and subtle enough that I want to make sure. This is more than just a case of the above being user error. In the case of the Learning map domain, I am planning to propose that the learningContentRef topicref specialization set "to-content" as the default value for @chunk, reflecting the general SCORM requirement that all content be rendered as a single leaf HTML page (or equivalent) in a SCORM package. But if the current Toolkit behavior is correct per the spec, then it would very bad to set that default. Cheers, E. ---- Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc. email: firstname.lastname@example.org <mailto:email@example.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>