[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
The question is not whether or not the title can be "displayed" but whether or not the topicref contributes to navigation when it has a title. "display" is way too inspecific--what context? A map viewer in an editor? Rendered output? A report of all the topicrefs in a map? By focusing on navigation/not navigation we avoid any need to discuss the rendition implications. For example, in a map viewer I might choose to display a topicgroup's navigation title even though it doesn't contribute to navigation simply because, since the author put it there, they presumably want to see it. Cheers, E. On 8/27/10 10:09 AM, "Bruce Nevin (bnevin)" <bnevin@cisco.com> wrote: > 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 >> >> -- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.reallysi.com www.rsuitecms.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]