Re: [dita] What are the implications of <navref> for key space construction?

[Robert D Anderson <robander@us.ibm.com>]

As you say, navref is essentially a form of deferred navigation. As such
though - it is most common in my experience for this to be used when the
target map is not available to the author working with the current map.
That's actually the reason (as I understand it) for deferring the
navigation. In particular, authors building for Eclipse use this to
reference another component that may or may not be available. When the
other component is installed, the navref results in a TOC that pulls in the
other component's TOC entries. When it is not available, nothing is pulled
in.

So, I'm less certain that navrefs should be treated the same as maps
referenced via topicref - primarily because I have never treated them that
way in the past. The 1.1 specification also makes a distinction between the
two ways of referencing a map. It says that:
"The <navref> represents a pointer to another map which should be preserved
as a transcluding link rather than resolved. Output formats that support
such linking will integrate the target when displaying the referencing map
to an end user."

To me, this means that no attempt is made to retrieve the other map until
the content is displayed to a reader, so I would not expect it to be used
to set key values.

Any other thoughts?

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit

Eliot Kimber <ekimber@reallysi.com> wrote on 12/05/2009 01:21:43 PM:

> Eliot Kimber <ekimber@reallysi.com>
> 12/05/2009 01:21 PM
>
> To
>
> dita <dita@lists.oasis-open.org>
>
> cc
>
> Subject
>
> [dita] 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>