[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Navtitle and locktitle (reprise)
[Folks at Arbortext are still discussing this, as others are more familiar with this than I, but I want to put out some thoughts I've already heard.] It seems that that Robert is proposing that this be a special case for locktitle on the map element and it isn't a change to say that locktitle is inherited in the same way that some other DITA attributes are. One of us thinks we should leave the inheritance of locktitle as it's defined by the spec and fix the toolkit to match the spec. One concern with this suggested change is that if you allow the value to inherit, then you cannot "lock" a parent title independently of the child topics without having to go to each child element and specify locktitle=no. Another one of us thinks it would be better to make locktitle inherit across all elements in the hierarchy and not make a special case for just the map element (though this might be a bigger change than Robert is suggesting). Consider the example: <map locatitle="yes"> <topicref id="A" locktitle="no"> <topicref id="A1"/> </topicref> What is the value for locktitle for the topicref with id="A1"? If I understand Robert's proposal correctly (and I may not), the answer is "yes". With regular inheritance, the answer would be "no". paul > -----Original Message----- > From: Robert D Anderson [mailto:robander@us.ibm.com] > Sent: Wednesday, 2007 January 10 14:51 > To: dita@lists.oasis-open.org > Subject: [dita] Navtitle and locktitle (reprise) > > > Last spring I sent this proposal to the list about the treatment of > locktitle: > http://www.oasis-open.org/archives/dita/200603/msg00050.html > > The suggestion is that locktitle, when set on a map, apply to > the entire > map. When set anywhere else within a map, it applies only to > that element > (the current definition in the spec). Based on 1.0 spec, there is no > purpose for setting locktitle on map, so this should not break any > implementation. Defining this behavior for maps will allow > users to lock in > titles for each topicref in a map without setting locktitle on every > element. Whether or not that seems odd, I know of several > people doing it today, so it is a real-world scenario.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]