[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
It is not true that its semantic of not contributing to navigation is inherent in its type. It's inherent in having neither a navigation title nor an associated resource. That is, a <topicref> element with no navigation title and no @href or @keyref attribute will be treated *exactly the same* as a <topicgroup> element with no <navtitle> grandchild. The question is whether a <topicgroup> element with a <navtitle> should be treated as though the navtitle wasn't there or if it should be treated as any other topicref that has a navtitle, regardless of specialization, would be treated (by default)? It bothers me a great deal to have an otherwise clean design marred by a special case that only the DITA spec itself can demand. That is, I cannot unilaterally specialize from map/topicref and declare, in my vocabulary documentation, that any navtitle for my specialization be ignored. All general-purpose DITA processors will be well within their rights to treat an instance of my specialization that happens to have a <navtitle> grandchild as it would any unspecialized topicref with a navigation title. Why should the DITA spec be special in this case? That is, we're proposing "all topicrefs, without exception, behave like 'X' except for this one type in this one vocabulary module". That just seems icky to me. The only other solution would be to have "groupness" be indicated by another, independent and non-cascading property of topicrefs, a property that could be set on any topicref, specialized or not. That is, if groupness is a property separate from the presence or absence of a navigation title, I shouldn't be required to specialize from mapgroup-d/topicgroup just to ensure that my specialized topicref is treated as a topic group, which is the implication of having topicgroup be a special case. There should be a way to indicate that any specialization of topicref is a group. Cheers, E. On 8/24/10 2:05 PM, "Nitchie, Chris" <cnitchie@ptc.com> wrote: > Normally I'd agree that if <navtitle> appeared within any <topicref> > specialization that didn't have @navtitle, standard processing applies. > But topicgroup is fundamentally different from other topicref > specializations in that it does not affect navigation hierarchy, and > there is nothing other than its tag name/class attribute to signify this > behavior. Unlike most other topicref specializations in mapgroup, such > as topichead and mapref, its specialness is not derived from default or > restricted attribute values in the DTD/Schema; it's inherent to itself. > I much prefer "topicgroup does not affect hierarchy," to "topicgroup > *usually* does not affect hierarchy." I think the latter would be > baffling to users and potentially tricky for processors. > > Chris > > -----Original Message----- > From: Eliot Kimber [mailto:ekimber@reallysi.com] > Sent: Tuesday, August 24, 2010 1:36 PM > To: Eliot Kimber; Bruce Nevin (bnevin); Doug Morrison; dita > Subject: Re: [dita] DITA 1.2 Review Comment: Thoughts on topicgroup, > navtitle, and locktitle > > The real answer would be to specialize <topicmeta> specifically for > <topicgroup> in the mapgroup domain in order to disallow <navtitle>. > That > would impose the same constraint that omitting @navtitle imposes and > would > be a more complete expression of the intention of topicgroup. > > Of course, such a change would not be backward compatible with 1.1, > which is > why we didn't do it in the first place. > > Thus the availability of <navtitle> as a descendant of <topicgroup> is > an > unavoidable consequence of that new markup design (which is itself > demanded > by localization requirements). > > Cheers, > > E. > > On 8/24/10 12:10 PM, "Eliot Kimber" <ekimber@reallysi.com> wrote: > >> On 8/24/10 10:43 AM, "Bruce Nevin (bnevin)" <bnevin@cisco.com> wrote: >> >>> For the confusion, here's a proposed clarification: >>> >>> In DITA 1.2, the <navtitle> element is optionally available within > the >>> <topicmeta> element. This has the unintended effect of making it >>> possible to specify <navtitle> within a <topicgroup>. Since the >>> <topicgroup> element is meant as a non-titled grouping element, > adding a >>> <navtitle> element to the <topicgroup> element has no defined > purpose, >>> and processors must ignore the title. Processors may (but need not) >>> issue a message when ignoring the title. >> >> I would correct this in two ways: >> >> 1. c/unintended/unavoidable/ >> >> 2. Rather than saying that processors must ignore the title I think we > must >> say that specifying a <navtitle> for <topicgroup> effectively makes it > into >> a topic head. >> >> That is, the semantics of topicrefs, as far as the DITA spec is > concerned, >> are entirely a function of what properties are or are not present for > a >> given topicref instance. The specializations in the map group domain > are >> simply syntactic conveniences, but they can't change the essential > meaning >> of a given combination of properties. >> >> Thus <topicgroup> is a syntactic convenience but cannot *impose* the >> semantic of groupness in the presence of an explicit navigation title. >> >> Or said another way, the interpretation of any topicref, in terms of > the >> DITA-defined semantics, should be invariant if I generalize > specialized >> topicrefs into the base topicref. >> >> Thus, >> >> <topicgroup> >> <topicmeta> >> <navtitle>foo</navtitle> >> </topicmeta> >> </topicgroup> >> >> generalizes into >> >> <topicref> >> <topicmeta> >> <navtitle>foo</navtitle> >> </topicmeta> >> </topicref> >> >> And would be correctly interpreted as a topic head, not a topic group. >> >> If this is not the case then I cannot have a completely generic > topicref >> handler that simply looks at the presence or absence of a navigation > title >> or a resource reference in order to distinguish topicrefs, topicheads, > and >> topic groups, but I would have to have a special case specifically for >> mapgroup-d/topicgroup. >> >> I think requiring that special case would be very very wrong. >> >> Cheers, >> >> Eliot >> >> -- >> 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 >> > > -- > 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 > -- 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]