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:
- Does Rob Frankland's use case degrade gracefully to this use
of standard mapref/map notation in lieu of using the topicset*
specialized notation?
- 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?)
- 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.)
--
"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot
|