OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]