If this is the case, then:the behavior of topicsetref with regard to keys is sufficiently established by the existing language for format="ditamap" references to topicrefs.
- 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.
--
Don R. Day
Founding Chair, OASIS DITA Technical Committee
LinkedIn: donrday Twitter: @donrday
About.me: Don R. Day Skype: 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
Where is the knowledge we have lost in information?"
--T.S. Eliot
| Virus-free. www.avast.com |