[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: What are the implications of <navref> for key space construction?
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]