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
