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: robander@us.ibm.com
Digital Services Group
11501 BURNET RD,, TX, 78758-3400, AUSTIN, USA

<dita@lists.oasis-open.org> wrote on 04/15/2016 09:52:03 AM: > From: Eliot Kimber <ekimber@contrext.com>
> To: <dita@lists.oasis-open.org>
> Date: 04/15/2016 09:49 AM
> Subject: Re: [dita] Key scopes and topicsetref
> Sent by: <dita@lists.oasis-open.org>
> > 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 <dita@lists.oasis-open.org> on behalf of Don Day < > donday@donrday.com> > Date: Friday, April 15, 2016 at 9:30 AM > To: dita <dita@lists.oasis-open.org> > 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

dita message