In 3.1.1.1.5 Navtitle, we say:
"Because the navtitle element is available within topicmeta, and
topicmeta is used in many different contexts, it is possible that
navtitle can be specified in contexts where a navigation title does not
make sense (for example, on the topicgroup element). In those
situations, the navtitle element has no defined purpose."
I suppose we could say something like:
"... Although the navtitle element has no defined purpose in those
situations, processors may nonetheless display a title."
/B
> -----Original Message-----
> From: Su-Laine Yeo [mailto:]
> Sent: Thursday, August 26, 2010 6:40 PM
> To: Bruce Nevin (bnevin); 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
>
> 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
>
> www.justsystems.com
> XMetaL Community Forums: http://forums.xmetal.com/
>
>
> -----Original Message-----
> From: Bruce Nevin (bnevin) [mailto:]
> 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:]
> > 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:]
> > > 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)"<> 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:]
> > > >>> 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
> > > >>>
> > > >>>
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > 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_workgr
oups.php
>
>
