I think we should use these opportunities as they present
themselves to identify markup that adds clutter to what might be
otherwise adequate semantics for the base spec. Perhaps some parts
can be deprecated, and others more clearly identified as corollary
to the core function by way of helping implementers use the core
function as much as possible. Robert has clarified for me before
on his points about default fallback behavior--easy to overlook if
you get caught up in semantics for what may be essentially a
semantic-free usage.
I started adding some foreward-looking discussion here but decided to put it in a separate note to keep this thread uncluttered. Look for "OPML" in an upcoming note to the list.
--
Don
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 GroupE-mail: robander@us.ibm.com
Digital Services Group11501 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
Founding Chair, OASIS DITA Technical Committee
LinkedIn: donrday Twitter: @donrday
About.me: Don R. Day Skype: don.r.day
Where is the knowledge we have lost in information?"
--T.S. Eliot
| Virus-free. www.avast.com |