[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 spaceconstruction?
Navref was in DITA 1.1--I had no idea. Obviously we can't replace it with a value of processing-role in that case. I must have always assumed it was a specialization of topicref. My questions about the implications for key resolution still stand, but I'll have to think about what I think the right answer should be in light of Robert's explanation. I'm not sure I agree with his assertion that the current language spec text implies anything but I'm also not sure what would be sensible. Cheers, E. On 12/6/09 8:21 PM, "Ogden, Jeff" <jogden@ptc.com> wrote: > 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 > -- 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]