[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
I understand the term "display" but I don't understand the term "contributes to navigation." Could someone explain the latter concept some other way please? I also don't understand the term "groupness." In any case (this might have been said amongst the things that I don't understand), there are at least five possible ways to process the following markup: <topicref href="Topic_A.xml"> <topicgroup><topicmeta><navtitle>Group B</navtitle></topicmeta> <topicref href="Topic_B1.xml"/> <topicref href="Topic_B2.xml"/> <topicref href="Topic_B3.xml"/> </topicgroup> These five ways are: Option 1: Topic A Group B Topic B1 Topic B2 Topic B3 Option 2: Topic A Topic B1 Topic B2 Topic B3 Option 3: Topic A Group B Topic B1 Topic B2 Topic B3 Option 4: Topic A Topic B1 Topic B2 Topic B3 Option 5: Topic A Topic B1 Topic B2 Topic B3 I think what we need to decide which option is the preferred behaviour, which options are acceptable, and which options are not acceptable. Then we need to make sure it's communicated in the spec. Putting the above examples in the spec might be a good to do this. In my opinion, option 1 is the most desirable, option 2 is not ideal, and all the rest are bad. Su-Laine -----Original Message----- From: Eliot Kimber [mailto:ekimber@reallysi.com] Sent: Friday, August 27, 2010 8:19 AM To: Bruce Nevin (bnevin); Su-Laine Yeo; Grosso, Paul; Doug Morrison Cc: dita; Robert D Anderson; Nitchie, Chris 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]