Re: [dita] Key scopes and topicsetref

You're right, navref is not deprecated, just the use of @keyref on navref is deprecated.

I think I was projecting my very strong opinion that navref should be deprecated.

Cheers,

E.

----

Eliot Kimber, Owner

Contrext, LLC

http://contrext.com

From:  dita <> on behalf of Robert Anderson <>
Date:  Friday, April 15, 2016 at 10:03 AM
To:  Eliot Kimber <>
Cc:  dita <>
Subject:  Re: [dita] Key scopes and topicsetref

Quick comments on a couple of the facilities in your list:

> We have at least the following facilities in DITA 1.3:
> topicref-to-topicref links with format="ditamap"
> Navref (deprecated but still present)

Navref is not actually deprecated.

> Topicsetref, which seems to address the same requirements that 
> motivated navref but slightly less underspecified

I agree that there is a related motivation, but still think that we should not consider this a special facility or a special kind of DITA reference. It's a specialized topicref -- just like topichead, just like topicgroup, just like keydef -- that you can do something special with if you want, but where default fallback behavior is still appropriate for many or most situations.

Regards,
Robert D. Anderson 
DITA-OT lead and Co-editor DITA 1.3 specification,
Digital Services Group 

E-mail: 
Digital Services Group 

11501 BURNET RD,, TX, 78758-3400, AUSTIN, USA 

  

<> wrote on 04/15/2016 09:52:03 AM:

> From: Eliot Kimber <>
> To: <>
> Date: 04/15/2016 09:49 AM
> Subject: Re: [dita] Key scopes and topicsetref
> Sent by: <>
> 
> I would say that for DITA 2.0 we need to think pretty deeply about 
> the architecture of maps as regards the relationship of one map to 
> another map—things have been way underspecified and clearly reflect 
> a particular processing model or environment that does not 
> generalize well as currently specified.
> 
> We have at least the following facilities in DITA 1.3:
> topicref-to-topicref links with format="ditamap"
> Navref (deprecated but still present)
> Topicsetref, which seems to address the same requirements that 
> motivated navref but slightly less underspecified
> Cross-deliverable links using peer maps and key scopes. These make 
> the addressing completely unambiguous but do not, by themselves, 
> address the navigation aggregation requirements reflected by navref 
> and topicsetref
> There's lots to think about here and clearly competing ideas about 
> what the most appropriate technical solution is. I agree with Don 
> that specific processing environments and tools have inappropriately
> influenced the design of these features. We need to try to undo that
> as much as we can.
> 
> Cheers,
> 
> E.
> ----
> Eliot Kimber, Owner
> Contrext, LLC
> http://contrext.com
> 
> From: dita <> on behalf of Don Day <
> >
> Date: Friday, April 15, 2016 at 9:30 AM
> To: dita <>
> Subject: Re: [dita] Key scopes and topicsetref
> 
> On 4/14/2016 1:19 PM, Eliot Kimber wrote:
> the behavior of
> topicsetref with regard to keys is sufficiently established by the
> existing language for format="ditamap" references to topicrefs.
> If this is the case, then:
> 1. Does Rob Frankland's use case degrade gracefully to this use of 
> standard mapref/map notation in lieu of using the topicset* 
> specialized notation?
> 2. If so, should the TC consider deprecating this notation in the 
> DITA 2.0 timeframe? (along with providing commensurate best practice
> advice to users like Rob on how to use mapref to achieve whatever 
> benefits the topicset* markup was intended to provide?)
> 3. Either way, the discussion does suggest that "deferred 
> processing" is a generally useful but under-specified use case. I 
> think that deferred processing (and to some extent, dynamic 
> processing) should be lightly advised on, if at all, since 
> implementations may differ widely for reasons that have nothing to 
> do with "imperative processing" (to characterize, for example, why 
> PDF or static, CD-ROMable HTML builds can't reasonably use deferred 
> processing semantics--other than by providing hooks for who knows 
> what). And for the same reason, specializations that support a 
> particular implementation of deferred processing should be left to 
> those applications--we don't want to enshrine them as standardized 
> elements in the standard, imperative-oriented model. Which leads 
> back to using "imperative vs deferred" as a consideration for 
> deprecating topicset*, and using that rationale to assess future 
> proposals for additions to the standard. 
> (And lest it not be obvious, I am of the opinion that the DITA 1.x 
> processing model's imperative output mindset may still be subtly 
> influencing how we think about future of the DITA franchise.)
> -- 
> Don R. Day
> Founding Chair, OASIS DITA Technical Committee
> LinkedIn: donrday   Twitter: @donrday
> About.me: Don R. Day   Skype: don.r.day 
> "Where is the wisdom we have lost in knowledge?
> Where is the knowledge we have lost in information?"
> --T.S. Eliot 
> 
> [image removed] 
> 
> Virus-free. www.avast.com