[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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]