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