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


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
>> 
>> 

-- 
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]