[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Navtitle and locktitle
I know of several users who set the locktitle value on the <map> element to ensure that none of their titles are updated. If we change existing processing to never inherit the value, it will be a pretty extensive change for those users; they'll have to set the value on every topicref, and remember to set it on every new topicref in the future. I'd like to propose a compromise solution that would users to keep that function. We could change the toolkit behavior to match the spec for all elements within a map. However, for the map element itself, we treat the locktitle setting as a declaration for the entire map. It would still be possible to override the declared behavior selectively on individual topicrefs inside the map. Any agreement/disagreement? This would mean a slight change to the spec to describe locktitle's effect on the map element. Currently, given that the spec says not to inherit, there is no defined purpose for using @locktitle on the map element itself. Thanks- Robert D Anderson Authoring Tools Development Chief Architect, DITA Open Toolkit (507) 253-8787, T/L 553-8787 "Paul Prescod" <paul.prescod@bla stradius.com> To Robert D 03/14/2006 09:54 Anderson/Rochester/IBM@IBMUS AM cc <dita@lists.oasis-open.org> Subject RE: [dita] Navtitle and locktitle I would strongly prefer that locktitle is NOT inherited, just as navtitle is not inherited. > -----Original Message----- > From: Robert D Anderson [mailto:robander@us.ibm.com] > Sent: Tuesday, March 14, 2006 7:24 AM > To: Paul Prescod > Cc: dita@lists.oasis-open.org > Subject: RE: [dita] Navtitle and locktitle > > Hi Paul, > > You're right that the spec does not list @locktitle as inheritable. > > The DITA Toolkit's code (from the days before sourceforge and > OASIS) does treat it as inheritable. I know of at least one > good-sized group of users that, for better or for worse, > often sets the value to "no" on the map element. This lets > them be sure that map always reflects what they will see in > the navigation. > > So, I'd like to ask -- should this be an inheritable > attribute? Is anybody else making use of the locktitle > attribute today, and following the spec for behavior? For > people using the toolkit, changing to meet the spec will > break the expected behavior. If the TC feels that it should > be left as-is, I'll need to start preparing users for the > change in behavior, so it comes as less of a shock. > > Thanks- > > Robert D Anderson > Authoring Tools Development > Chief Architect, DITA Open Toolkit > (507) 253-8787, T/L 553-8787 > > > > > "Paul Prescod" > > <paul.prescod@bla > > stradius.com> > To > Robert D > > 03/08/2006 01:03 > Anderson/Rochester/IBM@IBMUS > PM > cc > > <dita@lists.oasis-open.org> > > Subject > RE: [dita] Navtitle > and locktitle > > > > > > > > > > > > > > > > > I do not believe that locktitle is inherited in DITA 1.0: > > http://docs.oasis-open.org/dita/v1.0/archspec/dita_spec_23_map > inher.html > > This also pertains to the other email where you discussed the > pernicious effects of inheritance in one context. > > > -----Original Message----- > > From: Robert D Anderson [mailto:robander@us.ibm.com] > > Sent: Thursday, February 23, 2006 12:09 PM > > To: Paul Prescod > > Cc: dita@lists.oasis-open.org > > Subject: Re: [dita] Navtitle and locktitle > > > > Hi Paul -- yes, that has also been my understanding. For > our users in > > IBM, we've created an editor macro that goes through to > refresh all of > > the navtitles in a map, though we do not do it > automatically. As with > > your description, the macro does not update navtitles for anything > > that sets or inherits locktitle="yes". > > > > Robert D Anderson > > IBM Authoring Tools Development > > Chief Architect, DITA Open Toolkit > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]