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)

Robert D Anderson <robander@us.ibm.com> wrote on 2007-01-11 07.51.27:
> 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).

Two observations:

1. I'm not aware of any other attribute or topicmeta element that behaves this way (propagates if declared on a map, but not when declared on a topicref).  To have only one attribute behave this way might be construed as a hack to support existing non-standard practice.  (Not itself a bad thing, but it shouldn't stop it being thought through properly.) What if @locktitle were allowed a third value, say "all", which implicitly propagates a "yes" to all children, no matter what it's applied to?  I'm thinking of the CSS cascade model here as prior art.  That would satisfy my orthogonality itch.

2. The behaviour of this with respect to nested maps (navref and mapref) needs to be stated too.  If I include a submap with @locktitle, what happens to its child topicrefs?  If I include a submap without @locktitle, but into a map with @locktitle, what happens then?

Deborah Pickett

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]