None of us likes being backed into an icky corner of inconsistency;
abstracting that layer of complaint about the 'unavoidable consequences'
of adding <navtitle> to <topicmeta>, we might be near a kind of churning
agreement in the problem description, with a may/must difference still
outstanding in the proposed solution.
It doesn't matter so much where <topicgroup> 'gets' its 'groupness'
from. I think you're in agreement that "A topicref that contains other
elements also has the semantic[s] of groupness. The distinguishing
feature of topicgroup is not that it has the semantic[s] of groupness,
but that the only semantic[s] it has is groupness."
The question is what exactly the 'groupness' of <topicgroup> amounts to
at processing time. What does the processor do about it? Doug, your
proposal sounds to me like:
1. Tell users not to specify <navtitle> in the <topicmeta> of
<topicgroup>, even though they can.
2. For those inevitable cases where they do this anyway, hey whatever
floats your boat, processor.
Eliot, you reject a laissez faire version of (2). For you, the spec
should say:
2. The processor MUST ignore <navtitle> in the <topicmeta> of
<topicgroup>, because "[T]o give a topicgroup a navtitle is to
contradict its reason for existence. That is why it has no navtitle
attribute."
Those quoted words of yours, Doug, are in agreement with what I quoted
from Eliot in the 2nd paragraph above; maybe agreement is not so far
away on this may/must distinction as well?
/B
> -----Original Message-----
> From: Eliot Kimber [mailto:]
> Sent: Wednesday, August 25, 2010 9:06 AM
> To: Doug Morrison
> Cc: dita; Robert D Anderson; Bruce Nevin (bnevin); Nitchie, Chris
> Subject: Re: [dita] DITA 1.2 Review Comment: Thoughts on
> topicgroup, navtitle, and locktitle
>
> On 8/25/10 7:02 AM, "Doug Morrison" <> wrote:
>
> > I think a topicgroup gets its semantic of groupness from:
> >
> > 1. its name
> > 2. its intent
> > 3. the syntax of being parent to a group of child elements.
>
> I disagree. A topicgroup gets its semantic of groupness *from
> not having a title*.
>
> In particular, item 3 is not distinguishing: any topicref
> with child topicrefs is a group. Likewise, the intent is not
> a distinguisher because you can only know the intent by
> looking at the name (and then knowing that a specific name
> has specific rules associated with it).
>
> That's the point I'm trying to make: currently any topicref
> acts as a group (does not affect navigation) IFF it has
> neither a navigation title nor a bound resource.
>
> So there are only two possible distinguishers for topicgroup:
>
> A. Lack of a navtitle (DITA 1.1)
> B. The specific type mapgroup-d/topicgroup (implication of
> new language in
> 1.2 trying to explain away unavoidable allowance of navtitle
> as descendant of topicgroup)
>
> I think (B) is the wrong thing to do but I will accept that
> decision if it is the consensus otherwise.
>
> But let's not pretend that this is anything other than a
> special case that privileges topicgroup in a way that no
> other DITA-defined topicref is privileged and in a way that
> no other non-DITA-defined topicref specialization can be
> privileged except by specializing from topicgroup.
>
> Also, saying "processors are free to ignore the navtitle of a
> topicgroup element" is making it a special case because it
> means I cannot simply have a rule that says "if no navtitle
> no effect on navigation". And it cannot be a "may" it must be
> a "must", as in, "topicgroup's with navigation titles MUST
> NOT contribute to navigation".
>
> Cheers,
>
> E.
>
> --
> Eliot Kimber
> Senior Solutions Architect
> "Bringing Strategy, Content, and Technology Together"
> Main: 512.554.9368
> www.reallysi.com
> www.rsuitecms.com
>
>
