atom feed26 messages in org.oasis-open.lists.ditaRE: [dita] DITA 1.2 Review Comment: T...
FromSent OnAttachments
Doug MorrisonAug 12, 2010 2:02 pm 
Bruce Nevin (bnevin)Aug 24, 2010 8:43 am 
Eliot KimberAug 24, 2010 10:10 am 
Eliot KimberAug 24, 2010 10:35 am 
Robert D AndersonAug 24, 2010 11:03 am 
Nitchie, ChrisAug 24, 2010 12:05 pm 
Eliot KimberAug 24, 2010 12:57 pm 
Nitchie, ChrisAug 24, 2010 1:10 pm 
Robert D AndersonAug 24, 2010 1:15 pm 
Eliot KimberAug 24, 2010 1:49 pm 
Doug MorrisonAug 25, 2010 5:01 am 
Eliot KimberAug 25, 2010 6:05 am 
Bruce Nevin (bnevin)Aug 25, 2010 7:13 am 
Eliot KimberAug 25, 2010 8:20 am 
Doug MorrisonAug 25, 2010 9:19 am 
Grosso, PaulAug 25, 2010 10:26 am 
Eliot KimberAug 25, 2010 10:28 am 
Bruce Nevin (bnevin)Aug 25, 2010 10:33 am 
Nitchie, ChrisAug 25, 2010 10:34 am 
Eliot KimberAug 25, 2010 10:36 am 
Eliot KimberAug 25, 2010 10:38 am 
Su-Laine YeoAug 26, 2010 3:39 pm 
Bruce Nevin (bnevin)Aug 27, 2010 8:09 am 
Eliot KimberAug 27, 2010 8:18 am 
Su-Laine YeoAug 27, 2010 4:07 pm 
Don DayAug 27, 2010 4:30 pm 
Subject:RE: [dita] DITA 1.2 Review Comment: Thoughts on topicgroup, navtitle, and locktitle
From:Bruce Nevin (bnevin) (bne@cisco.com)
Date:Aug 25, 2010 7:13:49 am
List:org.oasis-open.lists.dita

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:ekim@reallysi.com] 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" <dmor@dita4all.com> 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,