What are the implications of <navref> for key space construction?

[Eliot Kimber <ekimber@reallysi.com>]

Somehow I had never noticed <navref> before.

Navref is not a specialization of topicref, it is a new element type that
creates a map-to-map dependency where the integration of the referenced map
into the effective navigation tree is deferred (essentially a form of
deferred conref).

The current reference entry for navref doesn't say anything about how
navref-referenced maps contribute to the effective compound map they are
used in, in particular, how they contribute to the key space and how they
contribute relationship tables.

I think the only right answer is that navref-included maps are treated just
like maps referenced via topicref but I want to make sure this is the intent
of the Architects before I write words to that effect in the spec.

Looking at it now, navref seems unnecessary now that we have
@processing-role, in that the same effect could be achieved by adding a
value such as "deferred-navigation" to @processing-role (remember that we
invented processing-role after inventing <navref>).

As far as I can tell from the description of navref, causing navigation
integration to be deferred is the only thing navref does so a
processing-role value should be as good a signal as <navref> to a processor
that cares.

As it is, everywhere we talk about topic-ref referenced maps in the context
of any map-related processing involving the effective map tree, we now have
to also mention <navref>. Given that, replacing <navref> with a new
@processing-role value seems like the less-disruptive change to the spec.

Cheers,

Eliot

-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770
www.reallysi.com
www.rsuitecms.com