Re: [dita] Should Nested Topicrefs Be Allowed for format="ditamap"?

[Erik Hennum <ehennum@us.ibm.com>]

Hi, Eliot:

I'd agree that it doesn't make much sense to assert child navigation against a remote map (though it would make sense to assert child navigation against an anchor within a map).

We've had some discussion that navigation is only the default intepretation of a map -- that it really expresses relationships between content -- and I'd think that bears here. While the default interpretation doesn't make sense, I can imagine associating a map with design-time topics explaining the rationale for reusing the map in the context or guidelines for what goes in the referenced map and what in the context, with relationships to semantic definitions for classifying or filtering the content of the map in reuse, with relationships to properties for processing the map in context, and so on.


Hoping that's useful,


Erik Hennum
ehennum@us.ibm.com


Eliot Kimber <ekimber@reallysi.com> wrote on 03/06/2008 07:04:43 PM:

> I'm implementing my own chunk to-content processing and as a side effect
> of that implementing map-to-map refs. It occurred to me that having
> something like this:
>
> <topicref href=""submap-01.ditamap"" format="ditamap">
>    <topicref href=""foo.dita"/> > </topicref>
>
> Doesn't make a lot of sense since it's somewhat ambiguous where the
> subordinate topicref would effectively be relative to the contents of
> the target ditamap.
>
> I think this case should be disallowed but I haven't thought about it
> that deeply.
>
> This use of topicref has always seemed a little iffy to me. I would be
> happier with a new construct that was explicitly a map-to-map reference
> but I realize it's probably too late to make that design change for 1.2,
> if it would be appropriate to make it at all.
>
> But I think we should clarify the constraints in this case: either
> disallow the case above or state clearly what the effective result is.