OASIS Darwin Information Typing Architecture (DITA) TC

Last spring I sent this proposal to the list about the treatment of
locktitle:
http://www.oasis-open.org/archives/dita/200603/msg00050.html

I see it on the agenda for a few weeks, and then it disappears with no
discussion or action recorded. I feel certain that there was agreement on
it - but it may have just been verbal agreement between myself and Paul
Prescod at the DITA conference.

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.

More information is available by following the note chain. Are there any
problems with this? Does anybody remember a decision on this (I can't find
it in the archives)? I'd like to get it on to the agenda for next week, so
that it doesn't get lost again. If the TC agrees (again?), then I think it
could be added to the 1.1 architectural spec as a clarification of
locktitle.

Thanks-

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit
(507) 253-8787, T/L 553-8787

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

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 

Robert D Anderson <robander@us.ibm.com> wrote
on 2007-01-17 01.35.43:

> Also, I'm not sure that adding a third value would be easier

> to understand.

(Well, I did consider briefly suggesting an inheritable
version of @locktitle="no" for the sake of symmetry, but I thought
better of it lest it cloud my point.)
 
> I think you would have one value on an

> attribute that will inherit, vs. two values that do not.


I pulled this sentence out from your message because
I think it sums up our differences of opinion perfectly.  For me,
having an attribute value mean the same thing on all elements is important.
 For others, what element the attribute is on is just as important.
 Perhaps I dislike that because element names in DITA are, in the
face of specialization, not the Precambrian Shield of Stability that they
are in other XML schemas.

In any case, this isn't such a big deal that I am
going to kick up a big argument about it.  I just want us to be consistent
across the "do what I mean"/"say what you mean" spectrum.

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


That seems reasonable within the context of how @locktitle
has been proposed, yes.

--

Deborah Pickett

Deborah_Pickett@moldflow.com

[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:

Hi Paul,

> Consider the example:
>
>