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

["Grosso, Paul" <pgrosso@ptc.com>]

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

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