OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[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 

Consider the example:

<map  locatitle="yes">
<topicref  id="A"  locktitle="no">
  <topicref  id="A1"/>

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".


> -----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]