[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Navtitle and locktitle (reprise)
Hi Deborah, It's true that no other value on a map inherits in exactly this fashion. However, it does not really seem like a hack to me - it seems more like a logical interpretation of an attribute that is otherwise meaningless. I would expect that anybody setting locktitle on the map would already expect this behavior. Also, I'm not sure that adding a third value would be easier to understand. In that case, I think you would have one value on an attribute that will inherit, vs. two values that do not. Is that right? For map references - you're right that the effect needs to be stated. I would think that if you include a map while using locktitle on the reference, then that is equivalent to setting locktitle on the target map. Otherwise, if the map you pull in has a global locktitle setting, that global locktitle setting would be used. That's my initial impression of what would be the most logical, so please argue otherwise it seems odd. Robert D Anderson IBM Authoring Tools Development Chief Architect, DITA Open Toolkit (507) 253-8787, T/L 553-8787 Deborah_Pickett@m oldflow.com To 01/10/2007 05:00 dita@lists.oasis-open.org PM cc 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 Deborah_Pickett@moldflow.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]