RE: [dita] DITA 1.2 Review Comment: Thoughts on topicgroup, navtitle, and locktitle

["Nitchie, Chris" <cnitchie@ptc.com>]

Normally I'd agree that if <navtitle> appeared within any <topicref>
specialization that didn't have @navtitle, standard processing applies.
But topicgroup is fundamentally different from other topicref
specializations in that it does not affect navigation hierarchy, and
there is nothing other than its tag name/class attribute to signify this
behavior. Unlike most other topicref specializations in mapgroup, such
as topichead and mapref, its specialness is not derived from default or
restricted attribute values in the DTD/Schema; it's inherent to itself.
I much prefer "topicgroup does not affect hierarchy," to "topicgroup
*usually* does not affect hierarchy." I think the latter would be
baffling to users and potentially tricky for processors.
 
Chris

-----Original Message-----
From: Eliot Kimber [mailto:ekimber@reallysi.com] 
Sent: Tuesday, August 24, 2010 1:36 PM
To: Eliot Kimber; Bruce Nevin (bnevin); Doug Morrison; dita
Subject: Re: [dita] DITA 1.2 Review Comment: Thoughts on topicgroup,
navtitle, and locktitle

The real answer would be to specialize <topicmeta> specifically for
<topicgroup> in the mapgroup domain in order to disallow <navtitle>.
That
would impose the same constraint that omitting @navtitle imposes and
would
be a more complete expression of the intention of topicgroup.

Of course, such a change would not be backward compatible with 1.1,
which is
why we didn't do it in the first place.

Thus the availability of <navtitle> as a descendant of <topicgroup> is
an
unavoidable consequence of that new markup design (which is itself
demanded
by localization requirements).

Cheers,

E.

On 8/24/10 12:10 PM, "Eliot Kimber" <ekimber@reallysi.com> wrote:

> On 8/24/10 10:43 AM, "Bruce Nevin (bnevin)" <bnevin@cisco.com> wrote:
> 
>> For the confusion, here's a proposed clarification:
>> 
>> In DITA 1.2, the <navtitle> element is optionally available within
the
>> <topicmeta> element. This has the unintended effect of making it
>> possible to specify <navtitle> within a <topicgroup>. Since the
>> <topicgroup> element is meant as a non-titled grouping element,
adding a
>> <navtitle> element to the <topicgroup> element has no defined
purpose,
>> and processors must ignore the title. Processors may (but need not)
>> issue a message when ignoring the title.
> 
> I would correct this in two ways:
> 
> 1. c/unintended/unavoidable/
> 
> 2. Rather than saying that processors must ignore the title I think we
must
> say that specifying a <navtitle> for <topicgroup> effectively makes it
into
> a topic head.
> 
> That is, the semantics of topicrefs, as far as the DITA spec is
concerned,
> are entirely a function of what properties are or are not present for
a
> given topicref instance. The specializations in the map group domain
are
> simply syntactic conveniences, but they can't change the essential
meaning
> of a given combination of properties.
> 
> Thus <topicgroup> is a syntactic convenience but cannot *impose* the
> semantic of groupness in the presence of an explicit navigation title.
> 
> Or said another way, the interpretation of any topicref, in terms of
the
> DITA-defined semantics, should be invariant if I generalize
specialized
> topicrefs into the base topicref.
> 
> Thus,
> 
> <topicgroup>
>  <topicmeta>
>    <navtitle>foo</navtitle>
>  </topicmeta>
> </topicgroup>
> 
> generalizes into
> 
> <topicref>
>  <topicmeta>
>    <navtitle>foo</navtitle>
>  </topicmeta>
> </topicref>
> 
> And would be correctly interpreted as a topic head, not a topic group.
> 
> If this is not the case then I cannot have a completely generic
topicref
> handler that simply looks at the presence or absence of a navigation
title
> or a resource reference in order to distinguish topicrefs, topicheads,
and
> topic groups, but I would have to have a special case specifically for
> mapgroup-d/topicgroup.
> 
> I think requiring that special case would be very very wrong.
> 
> Cheers,
> 
> Eliot
> 
> --
> Eliot Kimber
> Senior Solutions Architect
> "Bringing Strategy, Content, and Technology Together"
> Main: 512.554.9368
> www.reallysi.com
> www.rsuitecms.com
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 

-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.reallysi.com
www.rsuitecms.com


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php