[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
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:su-laine.yeo@justsystems.com] > 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 > 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_workgr oups.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]