Re: [dita] Key scopes and topicsetref

[Eliot Kimber <ekimber@contrext.com>]

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

Virus-free. www.avast.com