[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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 <dita@lists.oasis-open.org> on behalf of Robert Anderson <robander@us.ibm.com> Date: Friday, April 15, 2016 at 10:03 AM To: Eliot Kimber <ekimber@contrext.com> Cc: dita <dita@lists.oasis-open.org> Subject: Re: [dita] Key scopes and topicsetref Quick comments on a couple of the facilities in your list:
<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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]