[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
First - you're certainly right that this is "unavoidable" rather than "unintended". The issue was known when we added <navtitle>, and could not be avoided. Second - as you say, we would ideally have a specialized topicmeta, but this was ruled out in discussion due to the backwards compatibility issue. I don't have a big problem with changing this so that topicgroup with a navtitle still uses the navtitle, on the grounds that it's easier for all concerned; however, that does run counter to the stated description of the topicgroup element. It's well within the rights of the spec to declare new behaviors associated with a new element, even if those require additional processing, so I don't think it's out of bounds for the spec to say "on this specialized element, the following item has no effect". I think we should discuss this again at next week's call. Changing the behavior of topicgroup on this item will require a vote, since this described behavior was specifically called out in the proposal for the new <navtitle> element. Robert D Anderson IBM Authoring Tools Development Chief Architect, DITA Open Toolkit From: Eliot Kimber <ekimber@reallysi.com> To: Eliot Kimber <ekimber@reallysi.com>, "Bruce Nevin (bnevin)" <bnevin@cisco.com>, Doug Morrison <dmorrison@dita4all.com>, dita <dita@lists.oasis-open.org> Date: 08/24/2010 01:44 PM 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]