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
On 4/15/2016 10:03 AM, Robert D
Anderson wrote:
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 Group
E-mail:
Digital Services
Group
11501 BURNET
RD,, TX, 78758-3400, AUSTIN, USA
<> wrote on 04/15/2016
09:52:03 AM:
> From: Eliot Kimber <>
> To: <>
> Date: 04/15/2016 09:49 AM
> Subject: Re: [dita] Key scopes and topicsetref
> Sent by: <>
>
> 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 <> on behalf of
Don Day <
> >
> Date: Friday, April 15, 2016 at 9:30 AM
> To: dita <>
> 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
--
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
