OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


At PTC we don't have any explicit support for navref, so I am a novice
about its use and haven't thought about it much.

But having said that, my thoughts are similar to Robert's -- that
processing of maps referenced by navref is deferred and so any key
definitions would be deferred as well either because the map isn't
available or processing key definitions earlier isn't the right thing to
do. 

I guess one could make an argument that processing of key definitions
and key resolution should be deferred in this case, but that seems like
it would require a big discussion and has huge implications for
processing and so probably isn't something we can consider for DITA 1.2.

Likewise, Eliot's thoughts of changes to make navref a specialization of
topicref using @processing-role just doesn't seem like something that
can be considered for DITA 1.2 or likely at all until DITA 2.0.

   -Jeff

> -----Original Message-----
> From: Robert D Anderson [mailto:robander@us.ibm.com]
> Sent: Sunday, December 06, 2009 11:41 AM
> To: Eliot Kimber
> Cc: dita
> Subject: Re: [dita] What are the implications of <navref> for key
space
> construction?
> 
> 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
> >
> 
> 
> ---------------------------------------------------------------------
> 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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]