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

[Eliot Kimber <ekimber@reallysi.com>]

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