[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] referencing a bookmap from a map
On 6/9/09 11:06 AM, "Michael Priestley" <mpriestl@ca.ibm.com> wrote: > Hi Jeff, > >> Topicref to bookmap: >> Chapters in the bookmap maintain their ?chapterness? >> Parts in the bookmap maintain their ?partness? > > If we think of a mapref as being parallel to a conref (basically a > shorthand for "pull the target hierarchy into this point in this > hierarchy, but push reltables to the end because they're not allowed > within a hierarchy") then we should discard the chapterness - just like we > discard <step>ness when we conref from a <li>. > > Otherwise we allow chapters to nest, and break any bookmap processors that > are expecting DTD-validated content. My initial reaction to this is that it is unnecessarily restrictive because map-to-map relationships are not really conref relationships (if you want conref, use conref) but looser composition (of compound map) relationships where the relevant constraints and processing implications cannot be known in advance. That is, when processing a map, a processor need not create a literal new map, but simply process the referenced map as it exists, with knowledge of the referencing context. In that case, the fact that the referenced topicref is a bookmap chapter may or may not be relevant and the user may or may not care. I think part of this discussion may result from an inherent bit of fuzziness in the design of map-to-map references, which is that there is no necessary well-defined thing that is the target of the reference to which, for example, a type check could be applied. That is, there is no requirement that a referenced map have exactly one root topicref. In the case where there is no single root topicref, there is nothing to which a topicref could be unambiguously checked except the map element itself, but the map element is not reliably distinguishing (consider the L&T map domain, which allows the inclusion of very specialized topicrefs into an otherwise unspecialized <map> element). So I think we are obligated to say that map-to-map references are unconstrained by the spec and its up to processors to decide what is or isn't meaningful for a give use instance. Certainly in my "library map" use case, where I want a map that points to multiple bookmaps, my intent is clear and I can implement processing that makes it sensible, and that processing will almost certainly not be to treat the entire map as a single virtual map instance document but to treat the library map as a set of navigations to the otherwise individual bookmaps. There's nothing in the current DITA language that lets me express this intent directly (unless it's possibly scope="peer" on a map-to-map reference, but scope="peer" is seriously underspecified in the 1.2 spec as currently drafted and certainly doesn't address this particular question). I would be very uncomfortable saying that processors are *obligated* to treat references to specialized topicrefs as generalized. I would be OK with saying they *can* treat them as generalized. I would also be OK with saying that the type= attribute can indicate the type of the top-level topicrefs a given map-to-map reference effectively addresses, e.g.: <topicref href="mybookchaptermap.ditamap" type="chapter"/> If this form of type= was required in order to preserve the specialized nature in processing referenced topicrefs, I would be OK with that, since it doesn't preclude the functionality but does make intent clearer and enables designers to build in constraints in specializations. Cheers, E. ---- 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]