[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, andlocktitle
> That is, I cannot unilaterally specialize from map/topicref and declare, in > my vocabulary documentation, that any navtitle for my specialization be > ignored. Why not? You should be perfectly within your rights to have your own vocabulary, with your own documentation, where your own documentation states something like "In this specialization of X, I'll process differently than my ancestor in this specific way." Any processor claiming support specifically for your vocabulary specialization must follow that rule; any other conforming DITA processor will (must) use the default fallback behavior. > 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. I would say that not only are they within their rights - this is what they must do if they do not have advance knowledge of your vocabulary. If they have advance knowledge, and are aware of any style or processing rules you've defined, then they can enable support for your module (following the rules) or rely on the fallback support (still valid as a DITA processor). I'm speaking in more of a general case, rather than specifically regarding topicgroup, but I do feel that (if we wish) the same logic allows us to say that topicgroup acts counter to its specialization ancestor. I agree that for topicgroup and navtitle it has an icky feel, but I don't think it's invalid. Robert D Anderson IBM Authoring Tools Development Chief Architect, DITA Open Toolkit Eliot Kimber <ekimber@reallysi.com> wrote on 08/24/2010 03:57:44 PM: > From: Eliot Kimber <ekimber@reallysi.com> > To: "Nitchie, Chris" <cnitchie@ptc.com>, "Bruce Nevin (bnevin)" > <bnevin@cisco.com>, Doug Morrison <dmorrison@dita4all.com>, dita > <dita@lists.oasis-open.org> > Date: 08/24/2010 04:00 PM > 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 > > > --------------------------------------------------------------------- > 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]