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)

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

             01/10/2007 05:00          dita@lists.oasis-open.org           
             PM                                                         cc 
                                       Re: [dita] Navtitle and locktitle   

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]