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

["Su-Laine Yeo" <su-laine.yeo@justsystems.com>]

FWIW Doug's last post makes sense to me. If a writer does put a
<navtitle> grandchild into <topicgroup>, the only behaviour that will
not surprise them is for the processor to display the contents of the
navtitle. 

Su-Laine


Su-Laine Yeo
Solutions Consultant 
JustSystems Canada, Inc.
Office: 778-327-6356 
syeo@justsystems.com
www.justsystems.com 
XMetaL Community Forums: http://forums.xmetal.com/


-----Original Message-----
From: Bruce Nevin (bnevin) [mailto:bnevin@cisco.com] 
Sent: Wednesday, August 25, 2010 10:34 AM
To: Grosso, Paul; Doug Morrison; Eliot Kimber
Cc: dita; Robert D Anderson; Nitchie, Chris
Subject: RE: [dita] DITA 1.2 Review Comment: Thoughts on topicgroup,
navtitle, and locktitle

 

> -----Original Message-----
> From: Grosso, Paul [mailto:pgrosso@ptc.com] 
> Sent: Wednesday, August 25, 2010 1:27 PM
> To: Doug Morrison; Eliot Kimber
> Cc: Bruce Nevin (bnevin); dita; Robert D Anderson; Nitchie, Chris
> Subject: RE: [dita] DITA 1.2 Review Comment: Thoughts on 
> topicgroup, navtitle, and locktitle
> 
> >  Everyone happy?
> 
> Everyone except the implementors that are just about at code 
> freeze for the current release and won't have time to change 
> their implementations for another 12 months--and all their 
> users and anyone their users interchange DITA with for the 
> next couple years.

... that subset who fall into this edge case by using <topicgroup> in a
kind of strange, counterintuitive, nay self-contradictory way.

	/B

> 
> paul
> 
> > -----Original Message-----
> > From: Doug Morrison [mailto:dmorrison@dita4all.com]
> > Sent: Wednesday, 2010 August 25 11:20
> > To: Eliot Kimber
> > Cc: Bruce Nevin (bnevin); dita; Robert D Anderson; Nitchie, Chris
> > 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?
> > 
> > Regards,
> > 
> > Doug Morrison
> > Information Architect
> > http://dita4all.com
> > 
> > 
> > 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
> > >>>
> > >>>
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the 
> OASIS TC that 
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > 
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php