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

  My thinking was "a topicgroup needs a navtitle just like a fish needs 
a bicycle" so let's not force processors to do any unnecessary 
processing - just do what is easiest. However, there are strong 
arguments for consistency (as exemplified by the "Copy Exact" strategy 
of Intel).

I also thought that Eliot's view of the origin of 'groupness', however 
technically correct, was inconsistent with what common mortals like 
myself think. However, this really doesn't matter, as users should not 
not provide a navtitle as a grandchild of topicgroup in the first place.

So, my revised view is:

1. The topicgroup element should not be given a navtitle grandchild, 
even though permitted by the DTD. If you want to have a navtitle 
grandchild then you should use a topichead or topicref element (or 
specialisations thereof).
2. If, in spite of the advice to the contrary, a topicgroup element has 
a navtitle grandchild, it must be processed as though it were a topichead.

The behaviour may strike some as odd, but there is sound logic behind it 
(as given by Eliot). Moreover, I don't see that anyone has any good 
grounds for complaint: if you want a navtitle to be used for navigation, 
use topichead or topicref (or specializations thereof), if you don't 
want a navtitle to be used for navigation don't provide one (or don't 
set locktitle="yes"). If you design processors then it should work as 
defined above without creating any special privileged case for 
topicgroup. Everyone happy?


Doug Morrison
Information Architect

On 25/08/2010 16:20, Eliot Kimber wrote:
> I'm saying that in DITA 1.1 topicgroup gets its groupness from having
> neither a navtitle nor a bound resource. Because in DITA 1.1 the
> mapgroup-d/topicgroup element could never have either @navtitle or @href, it
> was impossible for it to have a navigation title. This meant that there was
> no need for topicgroup to be processed specially since *simply be dint of
> having no title and no bound resource* it *could not* contribute to
> navigation (there is nothing to navigate to).
> Thus in DITA 1.1 the "groupness" of topicgroup is inherent its allowed
> syntactic construction.
> In DITA 1.2, because we introduced<navtitle>  to<topicmeta>, it is
> unavoidable that topicgroup may have a title because there is no way in DTD
> or XSD syntax to prevent it.
> Thus DITA 1.2 raises the question of whether topicgroup should be given
> privileged status that requires that processors treat it as though it had no
> navigation title for the purpose of determining navigation structure or
> whether a<topicgroup>  element that has a navtitle should be treated as a
> topichead, which it would be using DITA 1.1 rules (if a topicref has a
> navigation title and no bound resource then it is a topic heading and
> contributes to navigation unless @toc="no").
> That is, is "groupness" a side effect of not having a navigation title and
> bound resource or is it an essential property of a specific subclass of
> topicrefs, topicrefs that are or specialize from mapgroup-d/topicgroup?
> I definitely reject a SHOULD for ignoring the navigation title of
> topicgroup: either it is *always* ignored or it is *never* ignored. There
> can be no middle ground. Otherwise the current DITA-defined rules for
> contribution to navigation are clear, unambiguous, and non-optional. The
> spec provides all the controls needed to precisely express authorial intent.
> There is no need to give processor option in this case nor should we want
> to--wherever we can ensure consistency of behavior we should (nee must) do
> so. This is definitely one of those cases.
> This is why I stress that defining the behavior of topicgroup as ignoring
> any navigation title as being a special case that all general DITA
> processors *must* implement.
> Cheers,
> E.
> On 8/25/10 9:14 AM, "Bruce Nevin (bnevin)"<bnevin@cisco.com>  wrote:
>> 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:ekimber@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"<dmorrison@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,
>>> E.
>>> --
>>> 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]